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@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
