Re: [BENCHMARK] contest 0.50 results to date

From: Rodrigo Souza de Castro (rcastro@ime.usp.br)
Date: Sat Oct 05 2002 - 15:56:27 EST


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

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



This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:51 EST