Re: [Ext2-devel] Re: [PATCH] concurrent block allocation for ext2 against 2.5.64

[William Lee Irwin III <wli@holomorphy.com>]

>>>>> William Lee Irwin (WLI) writes:
>> I simple use own pretty simple test. btw, you may disable
>> preallocation to increase allocation rate

WLI> This looks very interesting, but it may have to wait ca. 24
WLI> hours for some benchmark time b/c of the long boot times and
WLI> late hour in .us.
WLI> This also looks like it would be a much better stress test, and
WLI> the NUMA-Q is known for bringing out many rare races. There is
WLI> are good reasons to run this test even aside from performance.

On Sat, Mar 15, 2003 at 11:32:28AM +0300, Alex Tomas wrote:
> fine. it's really interesting to see results for so big iron.
"
So maybe it's pointless to elaborate on this in particular, but...

I actually borrowed time on the extra quads (I have 4 that are primarily
used by me; these systems support static partitioning, so as long as the
cabling is done right, you can make 4 4 quad systems from 16 quads, or
2 8 quad systems from 16 quads, or 1 16 quad system from 16 quads, etc.;
the other 4 are actually primarily used by Dave Hansen, but he's been
tied up with tasks that need him to use other systems this week and so
lent them to me) for the purpose of hardening pgcl (my forward port of
Hugh Dickins' page clustering patch), but when the issue of lock
contention came up, I thought it would be a good idea to utilize the
elevated cpu count to highlight the lock contention you were trying to
address with this patch. I'd be more than happy to see an effective
case for it made or otherwise demonstrate its merits.

I guess it's mostly OT and/or organizational, but it might (for those
who are interested) give an idea of how the time on these larger
systems is spent. In this case, the larger system is dynamically put
together from two smaller systems when another kernel hacker isn't
focusing on that system and nicely cooperates to give other people time
to test/benchmark/etc. on the hardware that can be glued together with
stuff regularly used by some other kernel hacker to form a larger system.
To some it might sound inconvenient, but I'm grateful for every minute
of time I get on the things.

There are other situations or "typical patterns" for getting at the
larger systems. What's probably the most typical pattern of all is that
the vendors themselves can't afford the larger models of their own
machines for kernel hacking purposes, and so the hackers (and their
managers and other kinds of helpers) scramble to beg, borrow, and steal
time on such machines from whatever places they can.

I have no idea what possessed me to describe all this, but I'll go on.
And sorry that this is probably very irrelevant to you Alex, but:

To all those who help get me in front of these, things, i.e. Dave, Hans,
Martin, Gerrit, Hubertus, et al, thanks a million! I love hacking on
big boxen, and (at least from the above) it's clear I can't do it alone.


-- wli