Re: Q: behaviour of mlockall(MCL_FUTURE) and VM_GROWSDOWN segments

[Richard Gooch]

Andrew Morton writes:
> Manfred Spraul wrote:
> > 
> > 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
> 
> 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.

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: [e-mail]
Current:   [e-mail]