[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150615143934.GA12300@akamai.com>
Date: Mon, 15 Jun 2015 10:39:34 -0400
From: Eric B Munson <emunson@...mai.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Shuah Khan <shuahkh@....samsung.com>,
Michal Hocko <mhocko@...e.cz>,
Michael Kerrisk <mtk.manpages@...il.com>,
linux-alpha@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mips@...ux-mips.org, linux-parisc@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, sparclinux@...r.kernel.org,
linux-xtensa@...ux-xtensa.org, linux-mm@...ck.org,
linux-arch@...r.kernel.org, linux-api@...r.kernel.org
Subject: Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked
on page fault
On Thu, 11 Jun 2015, Andrew Morton wrote:
> On Thu, 11 Jun 2015 15:21:30 -0400 Eric B Munson <emunson@...mai.com> wrote:
>
> > > Ditto mlockall(MCL_ONFAULT) followed by munlock(). I'm not sure
> > > that even makes sense but the behaviour should be understood and
> > > tested.
> >
> > I have extended the kselftest for lock-on-fault to try both of these
> > scenarios and they work as expected. The VMA is split and the VM
> > flags are set appropriately for the resulting VMAs.
>
> munlock() should do vma merging as well. I *think* we implemented
> that. More tests for you to add ;)
>
> How are you testing the vma merging and splitting, btw? Parsing
> the profcs files?
The lock-on-fault test now covers VMA splitting and merging by parsing
/proc/self/maps. VMA splitting and merging works as it should with both
MAP_LOCKONFAULT and MCL_ONFAULT.
>
> > > What's missing here is a syscall to set VM_LOCKONFAULT on an
> > > arbitrary range of memory - mlock() for lock-on-fault. It's a
> > > shame that mlock() didn't take a `mode' argument. Perhaps we
> > > should add such a syscall - that would make the mmap flag unneeded
> > > but I suppose it should be kept for symmetry.
> >
> > Do you want such a system call as part of this set? I would need some
> > time to make sure I had thought through all the possible corners one
> > could get into with such a call, so it would delay a V3 quite a bit.
> > Otherwise I can send a V3 out immediately.
>
> I think the way to look at this is to pretend that mm/mlock.c doesn't
> exist and ask "how should we design these features".
>
> And that would be:
>
> - mmap() takes a `flags' argument: MAP_LOCKED|MAP_LOCKONFAULT.
>
> - mlock() takes a `flags' argument. Presently that's
> MLOCK_LOCKED|MLOCK_LOCKONFAULT.
>
> - munlock() takes a `flags' arument. MLOCK_LOCKED|MLOCK_LOCKONFAULT
> to specify which flags are being cleared.
>
> - mlockall() and munlockall() ditto.
>
>
> IOW, LOCKED and LOCKEDONFAULT are treated identically and independently.
>
> Now, that's how we would have designed all this on day one. And I
> think we can do this now, by adding new mlock2() and munlock2()
> syscalls. And we may as well deprecate the old mlock() and munlock(),
> not that this matters much.
>
> *should* we do this? I'm thinking "yes" - it's all pretty simple
> boilerplate and wrappers and such, and it gets the interface correct,
> and extensible.
>
> What do others think?
I am working on V3 which will introduce the new system calls.
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists