Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it

[Vlastimil Babka <vbabka@suse.cz>]

On 07/10/2015 06:19 PM, Eric B Munson wrote:
> On Fri, 10 Jul 2015, Jonathan Corbet wrote:
>
>> On Thu, 9 Jul 2015 14:46:35 -0400
>> Eric B Munson <emunson@akamai.com> wrote:
>>
>>>> One other question...if I call mlock2(MLOCK_ONFAULT) on a range that
>>>> already has resident pages, I believe that those pages will not be locked
>>>> until they are reclaimed and faulted back in again, right?  I suspect that
>>>> could be surprising to users.
>>>
>>> That is the case.  I am looking into what it would take to find only the
>>> present pages in a range and lock them, if that is the behavior that is
>>> preferred I can include it in the updated series.
>>
>> For whatever my $0.02 is worth, I think that should be done.  Otherwise
>> the mlock2() interface is essentially nondeterministic; you'll never
>> really know if a specific page is locked or not.
>>
>> Thanks,
>>
>> jon
>
> Okay, I likely won't have the new set out today then.  This change is
> more invasive.  IIUC, I need an equivalent to __get_user_page() skips
> pages which are not present instead of faulting in and the call chain to
> get to it.  Unless there is an easier way that I am missing.

IIRC having page PageMlocked and put on unevictable list isn't necessary 
to prevent it from being reclaimed. It's just to prevent it from being 
scanned for reclaim in the first place. When attempting to unmap the 
page, vma flags are still checked, see the code in try_to_unmap_one(). 
You should probably extend the checks to your new VM_ flag as it is done 
for VM_LOCKED and then you shouldn't need to walk the pages to mlock 
them (although it would probably still be better for the accounting 
accuracy).

> Eric
>