> "David S. Miller" <davem@dm.cobaltmicro.com> writes:
>.....
> > On non-SMP I was getting 7% (consistantly) faster kernel builds with
> > the page coloring stuff on sparc64, and this is on boxes where memory
> > bandwidth is good enough that it shouldn't have shown up that much.
>
> I also tested Mark's preliminar page colouring patch, but results were
> different.
I guess that is the patch against 2.1.62, from my home-page, and not the
one against 2.1.60 or "proof-of-concept" patch I posted to the list a
couple of weeks ago.
> I got a small slowdown (< 2%) with the patch applied (638/628
> seconds user time, system time didn't change!?).
>
> I was compiling kernel (2.1.62) to test performance.
> I tried my best to make similar setup for the two compilings.
On my Pentium box, I was seeing only a small decrease in user-time for
compiling a kernel. By using a lazy-buddy, with a slight changed to the
traditional implementation (so that when the 'slack' of an order drops
below '2' the free-coalescing continues until it is '3'
(slack_high_mark)), the system-time is kept down to that of the
non-colouring page allocator. Although, being lazy, does increase the
fragmentation.
My 486 (8MB) showed a much better improvement (several percent, ~6%).
This is mainly due to kswapd running, which means the pte_young()
attribute is a reasonable measurement of how 'cache-hot' an anonymous page
is. Colouring, by itself, only gave a marginal improvement.
I'm sure you have done this, but I'll mention it to be safe.
When testing performance with a kernel compile, always compile the same
tree. Most importantly, make sure the free-space on your fs is similar
between runs. My fs is constantly hovering around 92% used. I can
see time differences between kernel compiles on a 90% and a 95% used
file-system. (I can't afford another disk.)
markhe