Messages in this thread | | | Date | Tue, 19 Jan 2010 14:07:12 +0200 | From | Gleb Natapov <> | Subject | Re: [PATCH v6] add MAP_UNLOCKED mmap flag |
| |
On Tue, Jan 19, 2010 at 11:54:42AM +0000, Alan Cox wrote: > > 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. > > So this isn't an API question this is an obscure corner case testing > question. > It is real use case scenario where the kernel doesn't provider me with enough rope. You, of course, can dismiss it as "obscure corner case". You can't expect issues with mlockall() which is corner case by itself to be mainstream, can you?
> > > > > > 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? > > And you want millions of users to have kernels with weird extra functions > whole sole value is one test environment you wish to run > We are talking about 4 lines of code that other people find useful too and they commented in this thread. This wouldn't be the first kernel feature not used by millions of people.
> See why we can't take you seriously either ? > I was taking about solutions. Thank you.
-- Gleb.
| |