Messages in this thread | | | Date | Tue, 1 Oct 2002 06:36:51 +1000 | From | Con Kolivas <> | Subject | Re: [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/
| |