From: Danilo Krummrich <dakr@kernel.org>
To: Mohamed Ahmed <mohamedahmedegypt2001@gmail.com>
Cc: James Jones <jajones@nvidia.com>,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
Mary Guillemard <mary@mary.zone>,
Faith Ekstrand <faith.ekstrand@collabora.com>,
Lyude Paul <lyude@redhat.com>,
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>,
nouveau@lists.freedesktop.org
Subject: Re: [PATCH v4 2/5] drm/nouveau/uvmm: Allow larger pages
Date: Wed, 5 Nov 2025 23:50:17 +0100 [thread overview]
Message-ID: <4d07932e-8b53-4ee3-8d08-6f49d433f005@kernel.org> (raw)
In-Reply-To: <CAA+WOBtmbPHigscFQCFgDo=9WSM6V-JMXGCO7orP=01XOqTPHQ@mail.gmail.com>
On 11/4/25 12:53 AM, Mohamed Ahmed wrote:
> Thanks a lot for the shout out! Looking more at things, the logic here
> is actually redundant. It was originally copied over directly from the
> bo allocation code to stay on the safer side (basically the idea back
> then was to make both the bo and vmm sides match exactly). We aren't
> at risk of having an aligned address that is in the wrong memory type
> because the bo allocation code (nouveau_bo.c:321) forces anything that
> has the GART flag to have a page size of 4K. Anything getting a page
> size higher than that is exclusively VRAM only. Additionally,
> currently things marked VRAM only don't get evicted to host memory
> except under high memory pressure and in that case, the context is
> paused until the objects in question are paged back in, so we also
> don't have to worry about memory placement there.
>
> The memory placement check in the vmm code could be removed but I am
> leaning more towards leaving it as is just to stay on the safer side.
If it is not necessary, please remove it. We should not carry dead code.
> At the same time, it would be more useful to keep it for the future as
> one of the future investigation targets that we want to look into is
> all the memory placement rules because the "only 4K is allowed for
> host memory" limit that nouveau imposes is a source of many pains in
> userspace (originally thought to be a HW thing but seems it's actually
> not), and having the checks on both bo and vmm paths would help
> starting out with that.
Please don't top-post, see also [1].
[1] https://subspace.kernel.org/etiquette.html#do-not-top-post-when-replying
next prev parent reply other threads:[~2025-11-05 22:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-31 10:49 [PATCH v4 0/5] drm/nouveau: Enable variable page sizes and compression Mohamed Ahmed
2025-10-31 10:49 ` [PATCH v4 1/5] drm/nouveau/uvmm: Prepare for larger pages Mohamed Ahmed
2025-10-31 10:49 ` [PATCH v4 2/5] drm/nouveau/uvmm: Allow " Mohamed Ahmed
2025-10-31 17:01 ` James Jones
2025-11-03 23:53 ` Mohamed Ahmed
2025-11-04 1:12 ` James Jones
2025-11-05 22:50 ` Danilo Krummrich [this message]
2025-11-08 19:30 ` Mary Guillemard
2025-11-05 22:51 ` Danilo Krummrich
2025-10-31 10:49 ` [PATCH v4 3/5] drm/nouveau/mmu/gp100: Remove unused/broken support for compression Mohamed Ahmed
2025-10-31 10:49 ` [PATCH v4 4/5] drm/nouveau/mmu/tu102: Add support for compressed kinds Mohamed Ahmed
2025-10-31 10:49 ` [PATCH v4 5/5] drm/nouveau/drm: Bump the driver version to 1.4.1 to report new features Mohamed Ahmed
2025-10-31 14:18 ` [PATCH v4 0/5] drm/nouveau: Enable variable page sizes and compression Mary Guillemard
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=4d07932e-8b53-4ee3-8d08-6f49d433f005@kernel.org \
--to=dakr@kernel.org \
--cc=airlied@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=faith.ekstrand@collabora.com \
--cc=jajones@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lyude@redhat.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mary@mary.zone \
--cc=mohamedahmedegypt2001@gmail.com \
--cc=mripard@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=simona@ffwll.ch \
--cc=tzimmermann@suse.de \
/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.