On Thu, Jun 25, 2015 at 7:16 AM, Eric B Munson wrote:
> On Tue, 23 Jun 2015, Vlastimil Babka wrote:
>
>> On 06/15/2015 04:43 PM, Eric B Munson wrote:
>> >>
>> >>If the new LOCKONFAULT functionality is indeed desired (I haven't
>> >>still decided myself) then I agree that would be the cleanest way.
On Tue, 23 Jun 2015, Vlastimil Babka wrote:
> On 06/15/2015 04:43 PM, Eric B Munson wrote:
> >>Note that the semantic of MAP_LOCKED can be subtly surprising:
> >>
> >>"mlock(2) fails if the memory range cannot get populated to guarantee
> >>that no future major faults will happen on the range.
> >
On 06/15/2015 04:43 PM, Eric B Munson wrote:
Note that the semantic of MAP_LOCKED can be subtly surprising:
"mlock(2) fails if the memory range cannot get populated to guarantee
that no future major faults will happen on the range.
mmap(MAP_LOCKED) on the other hand silently succeeds even if the
On Fri, 12 Jun 2015, Vlastimil Babka wrote:
> On 06/11/2015 09:34 PM, Andrew Morton wrote:
> >On Thu, 11 Jun 2015 15:21:30 -0400 Eric B Munson wrote:
> >
> >>>Ditto mlockall(MCL_ONFAULT) followed by munlock(). I'm not sure
> >>>that even makes sense but the behaviour should be understood and
> >
On Thu, 11 Jun 2015, Andrew Morton wrote:
> On Thu, 11 Jun 2015 15:21:30 -0400 Eric B Munson 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
On 06/11/2015 09:34 PM, Andrew Morton wrote:
On Thu, 11 Jun 2015 15:21:30 -0400 Eric B Munson 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 tr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/11/2015 03:34 PM, Andrew Morton wrote:
> On Thu, 11 Jun 2015 15:21:30 -0400 Eric B Munson
> wrote:
>
>>> Ditto mlockall(MCL_ONFAULT) followed by munlock(). I'm not
>>> sure that even makes sense but the behaviour should be
>>> understood and t
On Thu, 11 Jun 2015 15:21:30 -0400 Eric B Munson 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 th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 06/10/2015 05:59 PM, Andrew Morton wrote:
> On Wed, 10 Jun 2015 09:26:47 -0400 Eric B Munson
> wrote:
>
>> mlock() allows a user to control page out of program memory, but
>> this comes at the cost of faulting in the entire mapping when it
>> is
>
On Wed, 10 Jun 2015 09:26:47 -0400 Eric B Munson wrote:
> mlock() allows a user to control page out of program memory, but this
> comes at the cost of faulting in the entire mapping when it is
s/mapping/locked area/
> allocated. For large mappings where the entire area is not necessary
> this
mlock() allows a user to control page out of program memory, but this
comes at the cost of faulting in the entire mapping when it is
allocated. For large mappings where the entire area is not necessary
this is not ideal.
This series introduces new flags for mmap() and mlockall() that allow a
user
mlock() allows a user to control page out of program memory, but this
comes at the cost of faulting in the entire mapping when it is
allocated. For large mappings where the entire area is not necessary
this is not ideal.
This series introduces new flags for mmap() and mlockall() that allow a
user
12 matches
Mail list logo
