lkml.org 
[lkml]   [2002]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BENCHMARK] contest 0.50 results to date
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/

\
 
 \ /
  Last update: 2005-03-22 13:29    [W:0.059 / U:0.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site