![]() | |||||||||||||
Messages in this thread |
On Wed, 2005-06-01 at 17:22 +1000, michael@optusnet.com.au wrote: > Andi Kleen <ak@muc.de> writes: > > > fork is only a corner case. The main case is a process allocating > > memory using brk/mmap and then using it. > > Key point: "using it". This normally involves writes to memory. Most > applications don't commonly read memory that they haven't previously > written to. (valgrind et al call that behaviour a "bug" :). Then in that case you have doubled your memory bandwidth requirement for those cachelines. > > Given that, I'd say you really don't want the page zero routines > touching the cache. > The principle of locality-of-data (ie. the reason why caches even work) says that you do ;) Clearly some things benefit from not going through the cache. But I don't think we should fundamentally change behaviour of this *just* because it is worth a percent on kernel compiles. Also, I think that trends in CPU design (more cache, further from memory, multiple CPUs & cores) should favour stores going to cache rather than straight to memory... But I'm just speculating. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - 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/ | ||||||||||||
| Last update: 2005-06-01 08:05 [W:0.311 / U:0.160 seconds] ©2003-2008 Jasper Spaans | |||||||||||||