From: Alice Ryhl <aliceryhl@google.com>
To: Alexandre Courbot <acourbot@nvidia.com>
Cc: bshephar@bne-home.net, dakr@kernel.org, joelagnelf@nvidia.com,
jhubbard@nvidia.com, airlied@gmail.com,
rust-for-linux@vger.kernel.org, nouveau@lists.freedesktop.org,
brendan.shephard@gmail.com,
Nouveau <nouveau-bounces@lists.freedesktop.org>
Subject: Re: [PATCH 1/1] drm: nova: Align GEM memory allocation to system page size
Date: Wed, 26 Nov 2025 09:54:34 +0000 [thread overview]
Message-ID: <aSbOWhKIpCBm0NKL@google.com> (raw)
In-Reply-To: <DEI7BMSG3JTC.1Q0OZIUHCK4ZM@nvidia.com>
On Wed, Nov 26, 2025 at 09:31:46AM +0900, Alexandre Courbot wrote:
> On Tue Nov 25, 2025 at 11:59 PM JST, Alice Ryhl wrote:
> > On Tue, Nov 25, 2025 at 3:55 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
> >>
> >> On Tue Nov 25, 2025 at 11:41 PM JST, Alice Ryhl wrote:
> >> > On Tue, Nov 25, 2025 at 3:29 PM Alexandre Courbot <acourbot@nvidia.com> wrote:
> >> >>
> >> >> On Fri Nov 21, 2025 at 1:04 PM JST, bshephar wrote:
> >> >> > Use page::page_align for GEM object memory allocation to ensure the
> >> >> > allocation is page aligned. This ensures that the allocation is page
> >> >> > aligned with the system in cases where 4096 is not the default.
> >> >> > For example on 16k or 64k aarch64 systems this allocation should be
> >> >> > aligned accordingly.
> >> >> >
> >> >> > Signed-off-by: Brendan Shephard <bshephar@bne-home.net>
> >> >> > ---
> >> >> > drivers/gpu/drm/nova/gem.rs | 11 ++++++++---
> >> >> > 1 file changed, 8 insertions(+), 3 deletions(-)
> >> >> >
> >> >> > diff --git a/drivers/gpu/drm/nova/gem.rs b/drivers/gpu/drm/nova/gem.rs
> >> >> > index 2760ba4f3450..a07e922e25ef 100644
> >> >> > --- a/drivers/gpu/drm/nova/gem.rs
> >> >> > +++ b/drivers/gpu/drm/nova/gem.rs
> >> >> > @@ -3,6 +3,10 @@
> >> >> > use kernel::{
> >> >> > drm,
> >> >> > drm::{gem, gem::BaseObject},
> >> >> > + page::{
> >> >> > + page_align,
> >> >> > + PAGE_SIZE, //
> >> >> > + },
> >> >> > prelude::*,
> >> >> > sync::aref::ARef,
> >> >> > };
> >> >> > @@ -27,12 +31,13 @@ fn new(_dev: &NovaDevice, _size: usize) -> impl PinInit<Self, Error> {
> >> >> > impl NovaObject {
> >> >> > /// Create a new DRM GEM object.
> >> >> > pub(crate) fn new(dev: &NovaDevice, size: usize) -> Result<ARef<gem::Object<Self>>> {
> >> >> > - let aligned_size = size.next_multiple_of(1 << 12);
> >> >> > -
> >> >> > - if size == 0 || size > aligned_size {
> >> >> > + // Check for 0 size or potential usize overflow before calling page_align
> >> >> > + if size == 0 || size > usize::MAX - PAGE_SIZE + 1 {
> >> >>
> >> >> `PAGE_SIZE` here is no more correct than the hardcoded `1 << 12` - well,
> >> >> I'll admit it looks better as a placeholder. :) But the actual alignment
> >> >> will eventually be provided elsewhere.
> >> >
> >> > What about kernels with 16k pages?
> >>
> >> The actual alignment should IIUC be a mix of the GPU and kernel's
> >> requirements (GPU can also use a different page size). So no matter what
> >> we pick right now, it won't be great but you are right that PAGE_SIZE
> >> will at least accomodate the kernel.
> >
> > In that case, is PAGE_SIZE not the wrong constant? What's the actually
> > correct constant here?
> >
> >> >> > return Err(EINVAL);
> >> >> > }
> >> >> >
> >> >> > + let aligned_size = page_align(size);
> >> >>
> >> >> `page_align` won't panic on overflow, but it will still return an
> >> >> invalid size. This is a job for `kernel::ptr::Alignment`, which let's
> >> >> you return an error when an overflow occurs.
> >> >
> >> > The Rust implementation of page_align() is implemented as (addr +
> >> > (PAGE_SIZE - 1)) & PAGE_MASK, which definitely will panic on overflow
> >> > if the appropriate config options are enabled.
> >>
> >> That's right, I skimmed its code too fast. ^_^; All the more reason to
> >> use `Alignment`.
> >
> > Alignment stores values that are powers of two, not multiples of PAGE_SIZE.
>
> Isn't PAGE_SIZE always a power of two though?
Yes it is. Maybe you can elaborate on how you wanted to use Alignment?
It sounds like you have something different in mind than what I thought.
Alice
next prev parent reply other threads:[~2025-11-26 9:54 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-21 4:04 [PATCH 1/1] drm: nova: Align GEM memory allocation to system page size bshephar
2025-11-25 7:41 ` bshephar
2025-11-25 9:23 ` Alice Ryhl
2025-11-26 5:49 ` Brendan Shephard
2025-11-26 9:53 ` Alice Ryhl
2025-11-25 14:28 ` Alexandre Courbot
2025-11-25 14:41 ` Alice Ryhl
2025-11-25 14:55 ` Alexandre Courbot
2025-11-25 14:59 ` Alice Ryhl
2025-11-26 0:31 ` Alexandre Courbot
2025-11-26 9:54 ` Alice Ryhl [this message]
2025-11-26 13:22 ` Alexandre Courbot
2025-11-26 13:36 ` Alice Ryhl
2025-11-26 14:00 ` Alexandre Courbot
2025-11-26 16:24 ` Alice Ryhl
2025-11-26 21:14 ` Brendan Shephard
2025-11-26 6:05 ` Brendan Shephard
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=aSbOWhKIpCBm0NKL@google.com \
--to=aliceryhl@google.com \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=brendan.shephard@gmail.com \
--cc=bshephar@bne-home.net \
--cc=dakr@kernel.org \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=nouveau-bounces@lists.freedesktop.org \
--cc=nouveau@lists.freedesktop.org \
--cc=rust-for-linux@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.