From: "Danilo Krummrich" <dakr@kernel.org>
To: "Joel Fernandes" <joelagnelf@nvidia.com>
Cc: <linux-kernel@vger.kernel.org>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Jonathan Corbet" <corbet@lwn.net>,
"Alex Deucher" <alexander.deucher@amd.com>,
Christian König <christian.koenig@amd.com>,
"Jani Nikula" <jani.nikula@linux.intel.com>,
"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
"Vivi Rodrigo" <rodrigo.vivi@intel.com>,
"Tvrtko Ursulin" <tursulin@ursulin.net>,
"Rui Huang" <ray.huang@amd.com>,
"Matthew Auld" <matthew.auld@intel.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Lucas De Marchi" <lucas.demarchi@intel.com>,
Thomas Hellström <thomas.hellstrom@linux.intel.com>,
"Helge Deller" <deller@gmx.de>,
"Alice Ryhl" <aliceryhl@google.com>,
"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" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Trevor Gross" <tmgross@umich.edu>,
"John Hubbard" <jhubbard@nvidia.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>, "Edwin Peer" <epeer@nvidia.com>,
"Alexandre Courbot" <acourbot@nvidia.com>,
"Andrea Righi" <arighi@nvidia.com>,
"Andy Ritger" <aritger@nvidia.com>, "Zhi Wang" <zhiw@nvidia.com>,
"Balbir Singh" <balbirs@nvidia.com>,
"Philipp Stanner" <phasta@kernel.org>,
"Elle Rhumsaa" <elle@weathered-steel.dev>,
"Daniel Almeida" <daniel.almeida@collabora.com>,
<joel@joelfernandes.org>, <nouveau@lists.freedesktop.org>,
<dri-devel@lists.freedesktop.org>,
<rust-for-linux@vger.kernel.org>, <linux-doc@vger.kernel.org>,
<amd-gfx@lists.freedesktop.org>,
<intel-gfx@lists.freedesktop.org>,
<intel-xe@lists.freedesktop.org>, <linux-fbdev@vger.kernel.org>
Subject: Re: [PATCH -next v8 2/3] rust: gpu: Add GPU buddy allocator bindings
Date: Tue, 10 Feb 2026 22:10:02 +0100 [thread overview]
Message-ID: <DGBL94I0E5UB.4LNH3JODOKPV@kernel.org> (raw)
In-Reply-To: <1770754015.1979311.8126@nvidia.com>
On Tue Feb 10, 2026 at 9:09 PM CET, Joel Fernandes wrote:
>>> +impl GpuBuddyInner {
>>> + /// Create a pin-initializer for the buddy allocator.
>>> + fn new(params: &GpuBuddyParams) -> impl PinInit<Self, Error> {
>>
>> I think we can just pass them by value, they shouldn't be needed anymore after
>> the GpuBuddy instance has been constructed.
>
> Dave Airlie specifically reviewed this in RFC v6 and recommended passing by
> reference rather than by value [2]:
>
> "maybe we should pass them as non-mutable references, but I don't think
> there is any point in passing them by value ever."
>
> The params are also reused in practice -- the doc examples show the same
> `GpuBuddyParams` being used repeatedly. References
> avoid unnecessary copies for this reuse pattern.
Well, that's for GpuBuddyAllocParams, those are indeed reused and shouldn't be
copied all the time.
But my comment was about GpuBuddyParams, I don't see a reason those are reused
(neither are they in the example), so it makes more sense to pass them by value,
such that they are consumed. (I.e. I'm not asking for adding Copy/Clone.)
>
> [2] https://lore.kernel.org/all/CAPM=9tyL_Cq3+qWc4A41p7eqnNDLS1APUEeUbaQyJ46YDkipVw@mail.gmail.com/
>
>>> + pub fn new(params: &GpuBuddyParams) -> Result<Self> {
>>
>> Same here, we should be able to take this by value.
>
> Same reasoning as above.
>
>>> + pub fn alloc_blocks(&self, params: &GpuBuddyAllocParams) -> Result<Arc<AllocatedBlocks>> {
>>
>> Why do we force a reference count here? I think we should just return
>> impl PinInit<AllocatedBlocks, Error> and let the driver decide where to
>> initialize the object, no?
>>
>> I.e. what if the driver wants to store additional data in a driver private
>> structure? Then we'd need two allocations otherwise and another reference count
>> in the worst case.
>
> Good point. The reason I had `Arc` was to anticipate potential shared ownership
> use cases, but at the moment there is no such use case
> in nova-core -- each `AllocatedBlocks` has a single owner.
Sure, but drivers can always pass an impl PinInit to Arc::pin_init() themselves.
> I'll change this to return `impl PinInit<AllocatedBlocks, Error>` in the next
> version. If a shared ownership use case arises later, we
> can always add an `Arc`-returning convenience wrapper.
I don't think we should, don't give drivers a reason to go for more allocations
they actually need for convinience.
next prev parent reply other threads:[~2026-02-10 21:10 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-09 21:42 [PATCH -next v8 0/3] rust: Add CList and GPU buddy allocator bindings Joel Fernandes
2026-02-09 21:42 ` [PATCH -next v8 1/3] rust: clist: Add support to interface with C linked lists Joel Fernandes
2026-02-10 10:07 ` Danilo Krummrich
2026-02-11 21:09 ` Joel Fernandes
2026-02-11 21:17 ` Danilo Krummrich
2026-02-10 17:15 ` Daniel Almeida
2026-02-11 6:52 ` Claude review: " Claude Code Review Bot
2026-02-09 21:42 ` [PATCH -next v8 2/3] rust: gpu: Add GPU buddy allocator bindings Joel Fernandes
2026-02-10 11:55 ` Danilo Krummrich
2026-02-10 20:09 ` Joel Fernandes
2026-02-10 21:10 ` Danilo Krummrich [this message]
2026-02-10 21:43 ` Joel Fernandes
2026-02-10 22:06 ` Joel Fernandes
2026-02-10 23:23 ` Danilo Krummrich
2026-02-10 23:33 ` Joel Fernandes
2026-02-11 6:52 ` Claude review: " Claude Code Review Bot
2026-02-09 21:42 ` [PATCH -next v8 3/3] nova-core: mm: Select GPU_BUDDY for VRAM allocation Joel Fernandes
2026-02-10 10:10 ` Danilo Krummrich
2026-02-11 6:52 ` Claude review: " Claude Code Review Bot
2026-02-11 6:52 ` Claude review: rust: Add CList and GPU buddy allocator bindings Claude Code Review Bot
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=DGBL94I0E5UB.4LNH3JODOKPV@kernel.org \
--to=dakr@kernel.org \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=aliceryhl@google.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=apopple@nvidia.com \
--cc=arighi@nvidia.com \
--cc=aritger@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=daniel.almeida@collabora.com \
--cc=deller@gmx.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=elle@weathered-steel.dev \
--cc=epeer@nvidia.com \
--cc=gary@garyguo.net \
--cc=intel-gfx@lists.freedesktop.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=jhubbard@nvidia.com \
--cc=joel@joelfernandes.org \
--cc=joelagnelf@nvidia.com \
--cc=joonas.lahtinen@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fbdev@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.auld@intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=phasta@kernel.org \
--cc=ray.huang@amd.com \
--cc=rodrigo.vivi@intel.com \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
--cc=tursulin@ursulin.net \
--cc=tzimmermann@suse.de \
--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