On Tue, Jan 19, 2010 at 09:37:05AM +0200, Pekka Enberg wrote: > Hi Gleb, > > On Tue, Jan 19, 2010 at 9:17 AM, Gleb Natapov <gleb@xxxxxxxxxx> wrote: > > The thread took a direction of bashing mlockall(). This is especially > > strange since proposed patch actually makes mlockall() more fine > > grained and thus more useful. > > No, the thread took a direction of you not being able to properly > explain why we want MMAP_UNLOCKED in the kernel. It seems useless for It is needed in the kernel because this is the only proper (aka thread safe) way to mmap area bigger the main memory after mlockall(MCL_FUTURE). Do you agree we that? Now you can ask why is this needed and this is valid question. > real-time and I've yet to figure out why you need _mlockall()_ if it's > a performance thing. I don't do real-time so will not argue how useful it is for that, but it seems to me that people who argue that it is not useful for real time don't do it either and the only person in this thread who does real time uses mlockall(). Hmm strange. In my case (virtualization) I want to test/profile guest under heavy swapping of a guests memory, so I intentionally create memory shortage by creating guest much large then host memory, but I want system to swap out only guest's memory. > > It would be probably useful if you could point us to the application > source code that actually wants this feature. > This is two line patch to qemu that calls mlockall(MCL_CURRENT|MCL_FUTURE) at the beginning of the main() and changes guest memory allocation to use MAP_UNLOCKED flag. All alternative solutions in this thread suggest that I should rewrite qemu + all library it uses. You see why I can't take them seriously? -- Gleb. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
