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

["Christian König" <christian.koenig@amd.com>]

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