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

[Christian König]

Am 25.03.21 um 13:42 schrieb Jason Gunthorpe:
> On Thu, Mar 25, 2021 at 01:09:14PM +0100, Christian König wrote:
> > Am 25.03.21 um 13:01 schrieb Jason Gunthorpe:
> > > On Thu, Mar 25, 2021 at 12:53:15PM +0100, Thomas Hellström (Intel) wrote:
> > >
> > > > Nope. The point here was that in this case, to make sure mmap uses the
> > > > correct VA to give us a reasonable chance of alignement, the driver might
> > > > need to be aware of and do trickery with the huge page-table-entry sizes
> > > > anyway, although I think in most cases a standard helper for this can be
> > > > supplied.
> > > Of course the driver needs some way to influence the VA mmap uses,
> > > gernally it should align to the natural page size of the device
> > Well a mmap() needs to be aligned to the page size of the CPU, but not
> > necessarily to the one of the device.
> >
> > So I'm pretty sure the device driver should not be involved in any way the
> > choosing of the VA for the CPU mapping.
> No, if the device wants to use huge pages it must influence the mmap
> VA or it can't form huge pgaes.

No, that's the job of the core MM and not of the individual driver.

In other words current->mm->get_unmapped_area should already return a 
properly aligned VA.

Messing with that inside file->f_op->get_unmapped_area is utterly 
nonsense as far as I can see.

It happens to be this way currently, but that is not even remotely good 
design.

Christian.

> It is the same reason why mmap returns 2M stuff these days to make THP
> possible
>
> Jason