lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wijFJM9MHvwGSS4ADs8ncRagrXYi2E9SvhK8coMH32D7A@mail.gmail.com>
Date: Fri, 30 Aug 2024 14:32:13 +1200
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Dave Airlie <airlied@...il.com>
Cc: Daniel Vetter <daniel.vetter@...ll.ch>, dri-devel <dri-devel@...ts.freedesktop.org>, 
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm fixes for 6.11-rc6

On Fri, 30 Aug 2024 at 14:08, Dave Airlie <airlied@...il.com> wrote:
>
> The TTM revert is due to some stuttering graphical apps probably due
> to longer stalls while prefaulting.

Yeah, trying to pre-fault a PMD worth of pages in one go is just crazy talk.

Now, if it was PMD-aligned and you faulted in a single PMD, that would
be different. But just doing prn_insert_page() in a loop is insane.

The code doesn't even stop when it hits a page that already existed,
and it keeps locking and unlocking the last-level page table over and
over again.

Honestly, that code is questionable even for the *small* value, much
less the "a PMD size" case.

Now, if you have an array of 'struct page *", you can use
vm_insert_pages(), and that's reasonably efficient.

And if you have a *contiguous* are of pfns, you can use remap_pfn_range().

But that "insert one pfn at a time" that the drm layer does is
complete garbage. You're not speeding anything up, you're just digging
deeper.

                  Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ