Re: [PATCH] Simple Page Coloring (2.3.99pre3 diffs)

From: David S. Miller (davem@redhat.com)
Date: Wed Apr 12 2000 - 17:31:51 EST


   Date: Wed, 12 Apr 2000 17:19:32 -0400
   From: "Joseph A. Martin" <jmartin@linux08.mro.dec.com>

   Your real life is my arbitrary benchmark and vice versa.

Well, I claim it is not arbitrary in the context that I already know
that a poorly implemented coloring page allocator will show
performance problems with it :-)

Also, I know that this test creates interleaved page cache, buffer
cache, and user anon page allocations. This is a page allocation
pattern which can be good at creating fragmentation.

   It is my opinion that contemporary benchmarks are carefully
   designed and speak to the needs of some users.

This may be true, but we'd like Linux to run well for a variety
of users, not just some :-)

   Finally, here are my "time make -s vmlinux" results, which are much
   like yours:

... Thanks, uniprocessor numbers tend to be very useful as well since
such runs tend to eliminate much of the inter-run variance possibly
introduced due to scheduling etc.

Also, on SMP things like aging free pages (ie. putting them on the
tail of a free list at free time) tend to improve numbers (because
dirty pages tend to be written back to memory due to natural
replacement, thus no write update traffic when the next person who
gets the page writes to it).

I've been doing most of my recent work on uniprocessor to eliminate
these variables from my measurements, though it will be useful to
revisit such issues once the coloring allocator is in a good state.

Later,
David S. Miller
davem@redhat.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:19 EST