Re: PG_zero

[Andrea Arcangeli <andrea@novell.com>]

On Sat, Oct 30, 2004 at 02:07:32PM -0700, Andrew Morton wrote:
> I wonder if it would help if the page zeroing in the idle thread was done
> with the CPU cache disabled.  It should be pretty easy to test - isn't it
> just a matter of setting the cache-disable bit in the kmap_atomic()
> operation?

it's certainly an improvement I agree, however I don't measure a
slowdown here, so I'm not sure if it will make any significant
difference either. Plus the idle clearing code in theory could be
disabled and what would remain after that shall be an improvement over
current code.

I share your concern on the fact there seems not to be any speedup in my
2-way boxes unless I microbenchmark (but if I microbenchmark the best
case the speedup is very huge). OTOH the same applies to the per-cpu
queues at large, they only are measurable on the big boxes. Overall if
we've to use slab for the pte just to cache zero (which for sure won't
be a measurable speedup either in any small box using a _macro_
benchmark), this looks better design IMHO since it boosts everything
zero related, not just the pte. Plus it fixes some mistake in the
current code (like the failure of utilizing properly all the quicklists
belonging to each classzone [current code falls back into the buddy
before falling back in the lower zone quicklist] and the waste of
resouces in keeping the hot and cold caches separated, and the no point
for low watermark in the quicklists and other very minor details).

> There are quite a few patches happening in this area - the
> make-kswapd-aware-of-higher-order-pages patches and the no-buddy-bitmap
> patches are queued in -mm.  It'll take some time to work through them
> all...

Sure take your time (and this is only an experiment so far anyways).
Only I'll do the reject fixup after they're in mainline so I've less
chance of doing useless rediff work.