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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox