Messages in this thread | | | From | David Howells <> | Subject | Re: [PATCH] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag | Date | Fri, 30 Mar 2007 10:39:00 +0100 |
| |
Wu, Bryan <bryan.wu@analog.com> wrote:
> It takes lots of time in malloc()->mmap()->do_mmap_private()->memset(). When > malloc a big area, memset() the area to zero makes the performance very bad.
Ummm...
How do you then cope with attempting to run that same application under MMU-mode Linux? Won't MMU mmap() give EINVAL? If so, then that'd be grounds for NAK'ing this patch in the form given.
My theory is that NOMMU binaries should run just as well under an MMU-mode kernel as under a NOMMU kernel.
What you're asking for is also a security risk - though obviously on NOMMU-mode one that's fairly irrelevant. It might even make a lot of sense there to move the clearance into uClibc where possible rather than doing it in the kernel.
On MMU-mode kernels, the option should just be ignored.
I'd also recommend you stick a 'D' on the end of 'MAP_UNINITIALIZE' or may be call it MAP_UNCLEARED'. But that's a minor point, but you're not telling mmap() to go and uninitialise the memory...
Lastly, why do you actually need VM_UNINITIALIZE at all? The flag is only used in a place where MAP_UNINITIALIZE is still available (okay, you'll have to hand it down as an extra argument). That looks like a waste of a VM_xxx flag, and we don't have that many to spare.
David - 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/
| |