Messages in this thread | | | Date | Fri, 11 Jan 2002 16:45:31 -0700 | From | Richard Gooch <> | Subject | Re: Q: behaviour of mlockall(MCL_FUTURE) and VM_GROWSDOWN segments |
| |
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: rgooch@atnf.csiro.au Current: rgooch@ras.ucalgary.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |