On Wed, Apr 04, 2007 at 01:11:11PM -0700, David S. Miller wrote: > If we're going to consider this seriously, there is a case I know of. > Look at flush_dcache_page()'s test for ZERO_PAGE() on sparc64, there > is an instructive comment: > > /* Do not bother with the expensive D-cache flush if it > * is merely the zero page. The 'bigcore' testcase in GDB > * causes this case to run millions of times. > */ > if (page == ZERO_PAGE(0)) > return; > > basically what the GDB test case does it mmap() an enormous anonymous > area, not touch it, then dump core. > > As I understand the patch being considered to remove ZERO_PAGE(), this > kind of core dump will cause a lot of pages to be allocated, probably > eating up a lot of system time as well as memory.
Well, if we leave the zero page in because there may be too many apps to optimize, we still have to fix the zero page handling. Current code is far from ideal. Currently the zero page scales worse than no-zero-page, at the very least all the page count/mapcount increase/decrease at every map-in/zap must be dropped from memory.c, otherwise two totally unrelated gdb running at the same time (or gdb at the same time of fortran, or two unrelated fortran apps) will badly trash over the zero page reference counting. Besides the backwards compatibility argument with gdb or similar apps I doubt the zero page is a really worthwhile optimization and I guess we'd be better off if it never existed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
