Okay, so I've determined that my lousy AIM performance was my fault, not
a Linux problem -- I was using a set of subtests that include some that
saturate a single disk spindle. (I was using this fuller set of
subtests on a 4-Xeon system with a nicely striped/RAID filesystem, and
things ran compute-bound on that platform.)
So when I remove the non-computebound subtests from my mix, I see that
2.3.99pre8 behaves reasonably. My HP Kayak with 2-266MHz PentiumII
(512KB cache) executes only 30% faster than penguin3.engr, a 2-180MHz
R10000, despite having a core clock speed almost 50% faster. (The O200
has 128MB, the Kayak has 64MB, but neither system was swapping, so
memory isn't an issue at this load level.)
This particular mix of AIM subtests executes about 70% user, 30% system,
plus or minus 10%, on both systems. See
penguin3:/var/tmp/s7110/workfile for the specific subtest mix.
I believe we're ready to try this same test suite on an Origin and a
Xeon with more CPUs (and more main memory) and begin to examine the CPU
scaling curves. I have some 4-Xeon CPU scaling numbers in my files
somewhere, but those numbers were generated using an older kernel
version. My recollection is that the Xeon system I was using (dozin? I
forget) shows less-than-perfect scaling for a near-100% user-time
benchmark load (i.e., a 4-Xeon system performed only 3.8x better than
1-Xeon system, vs. an ideal 4.0x scaling), which I attributed to the
4-Xeon configuration beginning to saturate the memory bus. (You first
need to determine how a system scales using autonomous user-time
compute-bound loads, not the 70%/30% user/system loads, because you want
to keep kernel lock and I/O contention out of the picture.)
John Hawkes
|