Zeroed pages returned for heap

[Nagendra Singh Tomar <nagendra_tomar@adaptec.com>]

Hi all,
	The short version first.
Is it OK for an application (a C library implementing malloc/calloc is 
also an application) to assume that the pages returned by the OS for heap 
allocation (either directly thru brk() or thru mmap(MAP_ANONYMOUS)) will 
be zero filled. 

Now a lengthier version.

Linux zero fills all anonymous pages on allocation. This is _required_ for 
the C program BSS sections but _not_ _really_ required for heap pages. For 
heap pages the kernel zero fills them to avoid leaking any important 
information to users. On my target platform (Xscale) the memory access is 
such a big evil that I am constantly thinking of ways to avoid touching 
the damned memory as much as possible without any adverse effect on the 
kernel and applications behaviour. 
	One such way which I want to exploit is to not zero fill the heap 
pages (since mine is an embedded hardware, I do not care much abt leaking 
information out to users), since profiling has shown that the 
xscale_mc_clear_user_page function is taking lots of CPU time. When I 
implement that I see that few applications namely gcc and awk break. It 
seems that either the application or the C library is assuming about the 
pages returned by brk()/MAP_ANON, probably to improve calloc() efficiency 
( I'm not 100% sure on that as I've not yet looked at the code).
For testing I implemented this on x86 first and could boot the complete 
kernel and was able to start X, only that gcc used to crash.

I'll highly appreciate any informative views on this.

Thanx,
Tomar



-- You have moved the mouse. Windows must be restarted for the 
   changes to take effect.

-
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/