On Fri, 2006-03-24 at 09:19 -0800, dean gaudet wrote:

On Thu, 23 Mar 2006, Alex Izvorski wrote:

quoted

Also the cpu load is measured with Andrew Morton's cyclesoak
tool which I believe to be quite accurate.

there's something cyclesoak does which i'm not sure i agree with: 
cyclesoak process dirties an array of 1000000 bytes... so what you're 
really getting is some sort of composite measurement of memory system 
utilisation and cpu cycle availability.

i think that 1MB number was chosen before 1MiB caches were common... and 
what you get during calibration is a L2 cache-hot loop, but i'm not sure 
that's an important number.

i'd look at what happens if you increase cyclesoak.c busyloop_size to 8MB 
... and decrease it to 128.  the two extremes are going to weight the "cpu 
load" towards measuring available memory system bandwidth and available 
cpu cycles.

also for calibration consider using a larger "-p n" ... especially if 
you've got any cpufreq/powernowd setup which is varying your clock 
rates... you want to be sure that it's calibrated (and measured) at a 
fixed clock rate.

-dean

Dean - those are interesting ideas.  I tried them out, but they do not
appear to make much difference:  the measured load with busyloop_size of
128, 1M and 8M is the same within a couple of percent.  As far as I can
determine busyloop spends most of its time in the "for (thumb = 0; thumb
< twiddle; thumb++)" loop, and only touches about 150MB memory per
second (2.3M loops/sec, one cacheline or 64 bytes affected per loop).  I
don't have cpufreq so that's not a factor.  So far everything leads me
to believe that what cyclesoak reports is quite accurate.  I've even
confirmed it by timing other cpu-bound tasks (like compressing a file in
memory) and the results are essentially identical.

Regards,
--Alex