Re: [BENCHMARK] contest 0.50 results to date

[Rodrigo Souza de Castro]

On Sat, Oct 05, 2002 at 12:15:30PM -0700, Andrew Morton wrote:
> Paolo Ciarrocchi wrote:
> > 
[snip]
> > mem_load:
> > Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
> > 2.4.19 [3]              161.1   80      38      2       1.26
> > 2.4.19-0.24pre4 [3]     181.2   76      253     19      1.41
> > 2.5.40 [3]              163.0   80      34      2       1.27
> > 2.5.40-nopree [3]       161.7   80      34      2       1.26
> > 
> 
> I think I'm going to have to be reminded what "Loads" and "LCPU"
> mean, please.
> 
> For these sorts of tests, I think system-wide CPU% is an interesting
> thing to track - both user and system.  If it is high then we're doing
> well - doing real work.
> 
> The same isn't necessarily true of the compressed-cache kernel, because
> it's doing extra work in-kernel, so CPU load comparisons there need
> to be made with some caution.

Agreed. 

I guess the scheduling is another important point here. Firstly, this
extra work, usually not substantial, may change a little the
scheduling in the system.

Secondly, given that compressed cache usually reduces the IO performed
by the system, it may change the scheduling depending on how much IO
it saves and on what the applications do. For example, mem_load
doesn't swap any page when compressed cache is enabled (those data are
highly compressible), turning out to use most of its CPU time
slice. In vanilla, mem_load is scheduled all the time to service page
faults.

-- 
Rodrigo