> Time some kernel builds with the following combinations:
>
> 1) Vanilla-2.1.62
> 2) Vanilla-2.1.62 + page coloring patches
> 3) VGER from before I merged in the page coloring stuff
> (this is to get a measurement with the "need_resched hack"
> on SMP)
> 4) Most recent VGER (page coloring + "need_resched hack")
>
> 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 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.
BTW, I noticed that pages get swapped out rather fast when the colour
patch is in the kernel, probably because of that 'weak
defragmentation' Mark mentioned.
I experienced the same behaviour with my small patch intended to
prevent network blockups I was getting because of memory
fragmentation. So I stopped working on that and changed defines in
slab.c, so slab allocator doesn't need pages of high order while
transferring lots of data via network.
My setup: P133, 32MB RAM (256KB L2, pipeline burst).
-- Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr> --------------------------------------------------------------------- The Universe is a big place... perhaps the biggest