[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAAgWFh3rMwAwcaSCYsyaM0Q+yT5pf=teLQsAUJYyUbVHRQYjBQ@mail.gmail.com>
Date: Fri, 24 Oct 2025 14:38:08 -0400
From: M Henning <mhenning@...krefraction.com>
To: Lyude Paul <lyude@...hat.com>
Cc: Mohamed Ahmed <mohamedahmedegypt2001@...il.com>, Mary Guillemard <mary@...y.zone>,
Danilo Krummrich <dakr@...nel.org>, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org,
Faith Ekstrand <faith.ekstrand@...labora.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
nouveau@...ts.freedesktop.org
Subject: Re: [PATCH 2/5] drm/nouveau/uvmm: Allow larger pages
On Thu, Oct 23, 2025 at 4:52 PM Lyude Paul <lyude@...hat.com> wrote:
> One other change we should consider making though: can we make page_shift 32
> bit? A page shift of 32 would give us 2GB pages and I think that sounds way
> larger then anything we'd expect to encounter. Plus, we could just warn if we
> get a page shift larger then 32 bit and fail the ioctl. 64bit % 32bit should
> be faster and at least alleviate some of the overhead from the math here.
If the 64-bit modulo is a big concern, then this could also be
re-written to use bit arithmetic like this:
static bool
op_map_aligned_to_page_shift(const struct drm_gpuva_op_map *op, u8 page_shift)
{
u64 non_page_bits = (1ULL << page_shift) - 1;
return op->va.addr & non_page_bits == 0 &&
op->va.range & non_page_bits == 0 &&
op->gem.offset & non_page_bits == 0;
}
Powered by blists - more mailing lists