From: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
To: Zhi Wang <zhiw@nvidia.com>
Cc: "Wedson Almeida Filho" <wedsonaf@gmail.com>,
rust-for-linux@vger.kernel.org, "Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <benno.lossin@proton.me>,
"Andreas Hindborg" <a.hindborg@samsung.com>,
"Alice Ryhl" <aliceryhl@google.com>,
linux-kernel@vger.kernel.org,
"Wedson Almeida Filho" <walmeida@microsoft.com>,
"John Hubbard" <jhubbard@nvidia.com>, "Neo Jia" <cjia@nvidia.com>,
"Andy Currid" <acurrid@nvidia.com>
Subject: Re: [PATCH v3 00/10] Allocation APIs
Date: Thu, 2 May 2024 00:06:57 +0200 [thread overview]
Message-ID: <CANiq72nrMpg_dk4eM2Ve+aOi7QF4U-SCvLpx9PMD6o=6sdzOYQ@mail.gmail.com> (raw)
In-Reply-To: <20240408094738.00005e59.zhiw@nvidia.com>
On Mon, Apr 8, 2024 at 8:48 AM Zhi Wang <zhiw@nvidia.com> wrote:
>
> IMO, It seems the allocation flag here means GFP flags according to
> Patch 5 and I understand the benefit of introducing the flags.
>
> I am interested in the future plan. With this change, will Vec and Box
> stick to kernel memory application APIs with GFP flags in the future?
> e.g. GUP, kmalloc, those mostly allocates continuous memory for small
> objects. Is that the future for Vec and Box in kernel?
>
> Is there any plan for having vmalloc() in rust kernel? Currently, if I
> push a large object into a Vec, kernel MM will complain for sure. And
> literally Vec/Box themselves don't imply to the user that they allocate
> memory with limitations.
>
> Kernel uses different MM alloc APIs for different usages. For rust,
> should we have a different kind of "Vec/Box" or having a Vec/Box with
> different set of allocation flags that covers both GFP MM APIs and
> vmalloc()? I am curious about the plan.
Sorry Zhi, Danilo brought this message to my attention today (thanks!).
We have been trying to find the best way forward to support fallible
allocations, per-call-site flags, other kernel allocators and so on
for a long time, including discussions with upstream Rust.
At this point, after these years, I think the ideal path is to try our
best to avoid re-enabling `allocator_api` and to have perhaps our own
custom APIs/types as needed (possibly several depending on the use
case) -- please also see my reply at
https://lore.kernel.org/rust-for-linux/CANiq72=0BNw-KiURBjosLqfuUEPpjZPbRg1XMFZyobOzBt7aMA@mail.gmail.com/
Regarding this patch series, we mainly wanted to make progress on
(finally) allowing at least to use the GFP flags and also,
importantly, dropping `alloc` since we want to start supporting
several compiler versions soon.
Thank you for your feedback on this. It would be nice to hear what you
think about Danilo's approach in the other series and other possible
approaches that may not rely on `allocator_api`.
Cheers,
Miguel
next prev parent reply other threads:[~2024-05-01 22:08 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-28 1:35 [PATCH v3 00/10] Allocation APIs Wedson Almeida Filho
2024-03-28 1:35 ` [PATCH v3 01/10] rust: kernel: move `allocator` module under `alloc` Wedson Almeida Filho
2024-03-28 1:35 ` [PATCH v3 02/10] rust: alloc: introduce the `VecExt` trait Wedson Almeida Filho
2024-03-28 1:35 ` [PATCH v3 03/10] kbuild: use the upstream `alloc` crate Wedson Almeida Filho
2024-03-28 1:35 ` [PATCH v3 04/10] rust: alloc: remove our fork of the " Wedson Almeida Filho
2024-03-28 1:35 ` [PATCH v3 05/10] rust: alloc: introduce allocation flags Wedson Almeida Filho
2024-03-28 1:35 ` [PATCH v3 06/10] rust: alloc: introduce the `BoxExt` trait Wedson Almeida Filho
2024-03-29 17:59 ` Boqun Feng
2024-03-30 0:57 ` Wedson Almeida Filho
2024-03-30 13:35 ` Benno Lossin
2024-03-28 1:36 ` [PATCH v3 07/10] rust: alloc: update `VecExt` to take allocation flags Wedson Almeida Filho
2024-03-30 13:30 ` Benno Lossin
2024-03-28 1:36 ` [PATCH v3 08/10] rust: sync: update `Arc` and `UniqueArc` " Wedson Almeida Filho
2024-03-28 1:36 ` [PATCH v3 09/10] rust: init: update `init` module " Wedson Almeida Filho
2024-03-28 1:36 ` [PATCH v3 10/10] rust: kernel: remove usage of `allocator_api` unstable feature Wedson Almeida Filho
2024-03-29 18:25 ` [PATCH v3 00/10] Allocation APIs Boqun Feng
2024-03-29 23:23 ` Boqun Feng
2024-03-30 0:54 ` Wedson Almeida Filho
2024-04-08 6:47 ` Zhi Wang
2024-05-01 22:06 ` Miguel Ojeda [this message]
2024-04-16 21:03 ` Miguel Ojeda
2024-04-23 15:43 ` Danilo Krummrich
2024-04-25 15:36 ` Danilo Krummrich
2024-04-25 16:09 ` Benno Lossin
2024-04-25 18:03 ` Zhi Wang
2024-04-25 18:42 ` Danilo Krummrich
2024-04-25 20:52 ` Benno Lossin
2024-04-25 22:57 ` Danilo Krummrich
2024-04-26 6:32 ` Benno Lossin
2024-04-26 10:31 ` Danilo Krummrich
2024-04-29 20:14 ` Danilo Krummrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANiq72nrMpg_dk4eM2Ve+aOi7QF4U-SCvLpx9PMD6o=6sdzOYQ@mail.gmail.com' \
--to=miguel.ojeda.sandonis@gmail.com \
--cc=a.hindborg@samsung.com \
--cc=acurrid@nvidia.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=benno.lossin@proton.me \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=cjia@nvidia.com \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=walmeida@microsoft.com \
--cc=wedsonaf@gmail.com \
--cc=zhiw@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).