lkml.org 
[lkml]   [2002]   [Sep]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BENCHMARK] 2.5.39-mm1
Quoting Andrew Morton <akpm@digeo.com>:

> Con Kolivas wrote:
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Here follow the contest v0.41 (http://contest.kolivas.net) results for
> > 2.5.39-mm1:
> >
> > noload:
> > Kernel Time CPU Ratio
> > 2.4.19 67.71 98% 1.00
> > 2.5.38 72.38 94% 1.07
> > 2.5.38-mm3 73.00 93% 1.08
> > 2.5.39 73.17 93% 1.08
> > 2.5.39-mm1 72.97 94% 1.08
>
> 2.4.19 achieves higher CPU occupancy - you're using `make -j4', so it
> could be a CPU scheduler artifact, or a disk readahead latency effect.
>
> Is the kernel source in-cache for these runs?

Not cached. Swap should be empty and caches flushed prior to every load test.

>
> > process_load:
> > Kernel Time CPU Ratio
> > 2.4.19 110.75 57% 1.64
> > 2.5.38 85.71 79% 1.27
> > 2.5.38-mm3 96.32 72% 1.42
> > 2.5.39 88.9 75% 1.33*
> > 2.5.39-mm1 99.0 69% 1.45*
>
> Not sure what to make of this test. We have a bunch of tasks
> sending data between each other across pipes while trying to
> build a kernel.
>
> It could be that with 2.4.19, those piping processes got a lot
> more work done.
>
> I'd be inclined to drop this test; not sure what it means.

Err yeah...

>
> > io_load:
> > Kernel Time CPU Ratio
> > 2.4.19 216.05 33% 3.19
> > 2.5.38 887.76 8% 13.11
> > 2.5.38-mm3 105.17 70% 1.55
> > 2.5.39 229.4 34% 3.4
> > 2.5.39-mm1 239.5 33% 3.4
>
> I think I'll set fifo_batch to 16 again...
>

And I'll happily benchmark it when you do.

Con.
-
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.423 / U:0.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site