Page colouring

Zlatko Calusic (Zlatko.Calusic@CARNet.hr)
11 Nov 1997 01:59:29 +0100


"David S. Miller" <davem@dm.cobaltmicro.com> writes:

> 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