From: Con Kolivas <conman@kolivas.net>
To: Andrew Morton <akpm@digeo.com>
Cc: linux-kernel@vger.kernel.org, Jens Axboe <axboe@suse.de>
Subject: Re: [BENCHMARK] 2.5.39 with contest 0.41
Date: Sat, 28 Sep 2002 18:31:13 +1000 [thread overview]
Message-ID: <1033201873.3d9568d158a72@kolivas.net> (raw)
In-Reply-To: <3D95670C.3239A357@digeo.com>
Quoting Andrew Morton <akpm@digeo.com>:
> Con Kolivas wrote:
> >
> > Here follow the latest benchmarks with contest
> (http://contest.kolivas.net)
> >
> > 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
> >
> > 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.18 77% 1.30
>
> well that's funny.
>
> > 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 216.81 37% 3.20
>
> -mm3 has fifo_batch=16. 2.5.39 has fifo_batch=32.
>
> > mem_load:
> > Kernel Time CPU Ratio
> > 2.4.19 105.40 70% 1.56
> > 2.5.38 107.89 73% 1.59
> > 2.5.38-mm3 117.09 63% 1.73*
> > 2.5.39 103.72 72% 1.53
>
> 2.5's swapout is still fairly synchronously sucky. So low-latency
> writeout could be advantageous there. This difference is probably
> also the fifo_batch thing. Or maybe statistical?
>
>
> I did some testing with your latest. 4xPIII, mem=512m, SCSI,
> tag depth = 0, 2.5.39-mm1 candidate:
>
> fifo_batch=32:
>
> noload 2:34.53 291%
> cpuload 2:36.20 286%
> memload 2:19.44 333%
> ioloadhalf 2:34.81 303%
> ioloadfull 3:15.47 238%
>
> (err. memload sped it up!)
>
> fifo_batch=16:
>
> noload 2:00.03 380%
> cpuload 2:27.62 304%
> memload 2:22.59 326%
> ioloadhalf 2:33.75 306%
> ioloadfull 2:59.18 259%
>
> - Something went horridly wrong in the first `noload' test.
> - fifo_batch=16 is better than 32.
> - you see a 4x hit from io_load. I see a 1.5x hit.
>
> This is all pretty wild. I'll go profile process_load a bit.
>
>
>
> BTW, please change all the
>
> #define dprintf(...) printf(__VA_ARGS__)
>
> to
>
> #define dprintf(x...) printf(x)
>
> so people who use crufty old compilers can build it.
>
Ok will fix. But please Andrew use version 0.41 of contest (posted only 2 hours
ago). The results from that are far more meaningful and reproducible.
Con
next prev parent reply other threads:[~2002-09-28 8:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-28 6:58 [BENCHMARK] 2.5.39 with contest 0.41 Con Kolivas
2002-09-28 8:23 ` Andrew Morton
2002-09-28 8:31 ` Con Kolivas [this message]
2002-09-28 8:45 ` Andrew Morton
2002-09-28 9:08 ` Jens Axboe
2002-09-28 9:17 ` Con Kolivas
2002-09-28 15:17 Paolo Ciarrocchi
2002-09-28 23:59 ` Con Kolivas
2002-09-29 9:00 Paolo Ciarrocchi
2002-09-29 9:17 ` Con Kolivas
2002-09-29 17:14 Paolo Ciarrocchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1033201873.3d9568d158a72@kolivas.net \
--to=conman@kolivas.net \
--cc=akpm@digeo.com \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).