[PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
vbabka at suse.cz
Wed Jul 22 01:35:59 AEST 2015
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 at 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.
> 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
More information about the Linuxppc-dev