linux-kernel - Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Mar 2021 10:56:18 -0300
From:   Jason Gunthorpe <jgg@...dia.com>
To:     Christian König <christian.koenig@....com>
Cc:     Thomas Hellström (Intel) 
        <thomas_os@...pmail.org>, David Airlie <airlied@...ux.ie>,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 1/2] mm,drm/ttm: Block fast GUP to TTM huge pages

On Thu, Mar 25, 2021 at 02:54:31PM +0100, Christian König wrote:

> > The goal is to optimize large page size usage in the page tables.
> > 
> > There are three critera that impact this:
> >   1) The possible CPU page table sizes
> >   2) The useful contiguity the device can create in its iomemory
> >   3) The VA's alignment, as this sets an upper bound on 1 and 2
> > 
> > If a device has 256k pages and the arch supports 2M and 4k then the VA
> > should align to somewhere between 4k and 256k. The ideal alignment
> > would be to optimize PTE usage when stuffing 256k blocks by fully
> > populating PTEs and depends on the arch's # of PTE's per page.
> 
> Ah! So you want to also avoid that we only halve populate a PTEs as well!
> That rather nifty.
> 
> But you don't need the device page size for this. Just looking at the size
> of the mapping should be enough.

Well, kind of, at a certain point we start to over-align things which
is a bit harmful too, it is best to cap it at what the device could
actually use, IMHO.

Keep in mind address space is not free, and 32 bit in particular needs
to be efficient.

Jason