Q: behaviour of mlockall(MCL_FUTURE) and VM_GROWSDOWN segments
If an app has an VM_GROWS{DOWN,UP} stack and calls mlockall(MCL_FUTURE|MCL_CURRENT), which pages should the kernel lock?
* grow the vma to the maximum size and lock all.
* just according to the current size.
What should happen if the segment is extended by more than one page at once? (i.e. a function with 100 kB local variables)
* Just allocate the page that is needed to handle the page faults
* always fill holes immediately.
Right now segments are not grown during the mlockall syscall. Some codepaths fill holes (find_extend_vma()), most don't (page fault handlers)
What's the right thing (tm) to do?
I don't care which implementation is choosen, but IMHO all implementations should be identical
--
Manfred
Quoted 13 lines · Manfred Spraul
If an app has an VM_GROWS{DOWN,UP} stack and calls
mlockall(MCL_FUTURE|MCL_CURRENT), which pages should the kernel lock?* grow the vma to the maximum size and lock all.
* just according to the current size.What should happen if the segment is extended by more than one page at once? (i.e. a function with 100 kB local variables)
* Just allocate the page that is needed to handle the page faults
* always fill holes immediately.
Quoted 7 lines
Right now segments are not grown during the mlockall syscall. Some codepaths fill holes (
find_extend_vma()), most don't (page fault handlers)What's the right thing (tm) to do?
I don't care which implementation is choosen, but IMHO all implementations should be identical
This was a problem encountered when taking a libpthread-based
application from 2.4.7 to 2.4.15. It ran fine with mlockall
under 2.4.7, but under 2.4.15 everything wedged up. This was, I assume,
because under 2.4.15, the many pthread stacks were fully faulted in and
locked at mlockall() time. We ended up just not using mlockall
at all.
Really the 2.4.15 behaviour is correct, but undesirable. It requires each thread to know apriori what its maximum stack use will be. (I'm assuming that there's a way of setting a thread's stack size in libpthread).
So in this case, the behaviour I would prefer is MCL_FUTURE for
all vma's *except* the stack. Stack pages should be locked
only when they are faulted in. Hard call.
-
Quoted 29 lines · Andrew Morton
Quoted 13 lines · Manfred Spraul
If an app has an VM_GROWS{DOWN,UP} stack and calls
mlockall(MCL_FUTURE|MCL_CURRENT), which pages should the kernel lock?* grow the vma to the maximum size and lock all.
* just according to the current size.What should happen if the segment is extended by more than one page at once? (i.e. a function with 100 kB local variables)
* Just allocate the page that is needed to handle the page faults
* always fill holes immediately.Quoted 7 lines
Right now segments are not grown during the mlockall syscall. Some codepaths fill holes (
find_extend_vma()), most don't (page fault handlers)What's the right thing (tm) to do?
I don't care which implementation is choosen, but IMHO all implementations should be identicalThis was a problem encountered when taking a libpthread-based
application from 2.4.7 to 2.4.15. It ran fine with mlockall
under 2.4.7, but under 2.4.15 everything wedged up. This was, I assume,
because under 2.4.15, the many pthread stacks were fully faulted in and
locked atmlockall()time. We ended up just not using mlockall
at all.
Quoted 8 lines
Really the 2.4.15 behaviour is correct, but undesirable. It requires each thread to know apriori what its maximum stack use will be. (I'm assuming that there's a way of setting a thread's stack size in libpthread).
So in this case, the behaviour I would prefer is
MCL_FUTUREfor
all vma's *except* the stack. Stack pages should be locked
only when they are faulted in. Hard call.
How about controlling this with a MCL_STACK flag or some such? If there's no One True Path[tm], leave the decision to the application.
Regards, Richard.... Permanent: [email protected] Current: [email protected]