mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: grue@lakesweb.com
To: rml@tech9.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: Feedback on preemptible kernel patch
Date: Sun, 9 Sep 2001 11:57:24 -0700 (PDT)	[thread overview]
Message-ID: <20010909185727.586B1597C5@g-box.vf.shawcable.net> (raw)
In-Reply-To: <999928066.903.18.camel@phantasy>

Hi Rob,

Just finished running some benchmarks on my workstation.
Dual P3-550, 256MB ram, no swap, both kernels with CONFIG_SMP=y, 440BX,
2-20GB 5400rpm drives.

All benchmarks running in an Eterm on E on XF86-4.1.0-DRI with xmms running to
listen for latency probs. Benchmarks run as root, everything else as regular
user.

linux-2.4.10-pre6 with rml-netdev-random patch and rml-preempt patch (pre5 patches
applied to pre6), with CONFIG_PREEMPT=y

dbench 16
Throughput 23.4608 MB/sec (NB=29.326 MB/sec  234.608 MBit/sec)
Throughput 22.6915 MB/sec (NB=28.3644 MB/sec  226.915 MBit/sec) - .5sec hiccup in xmms
Throughput 20.4314 MB/sec (NB=25.5392 MB/sec  204.314 MBit/sec) - .5sec hiccup in xmms
Throughput 27.2849 MB/sec (NB=34.1061 MB/sec  272.849 MBit/sec) - .5sec hiccup in xmms
Throughput 20.5148 MB/sec (NB=25.6435 MB/sec  205.148 MBit/sec) - 2sec and .5sec in xmms
loadavg around 14

Bonnie
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
         1024  9002 98.0 15893 15.1  6519 10.8  6101 78.6 23330 24.4 104.3  2.2

linux-2.4.10-pre6

dbench 16
Throughput 18.1821 MB/sec (NB=22.7276 MB/sec  181.821 MBit/sec)
Throughput 22.4247 MB/sec (NB=28.0309 MB/sec  224.247 MBit/sec) - .5sec hiccup in xmms
Throughput 20.2662 MB/sec (NB=25.3328 MB/sec  202.662 MBit/sec) - 2sec hiccup in xmms
Throughput 28.4072 MB/sec (NB=35.5089 MB/sec  284.072 MBit/sec) - 3sec hiccup in xmms
Throughput 24.0549 MB/sec (NB=30.0686 MB/sec  240.549 MBit/sec)
loadavg around 14

Bonnie
              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
         1024  9173 99.4 16104 14.5  6488 10.2  6139 78.9 23260 22.1 105.1  2.3

There's no real difference in speed with either kernel, the hard drives
seem to be the bottleneck on this system.
-(root@g-box)-(~)-
->hdparm /dev/hda

/dev/hda:
 multcount    = 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  1 (on)
 nowerr       =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 2491/255/63, sectors = 40031712, start = 0

The throughput from bonnie is very close to the max physical throughput
of the drives, so I'm not to concerned that there isn't much of a
difference in speed.

The biggest difference is in the usability of the system under the load.
With 2.4.10-pre6 vanilla, dbench seriously affects the interactivity of
X, as well as causes some long interuptions in xmms. With preempt
enabled, this is much improved. Still some interuptions in xmms, but the
system is still usable, although a little sluggish. On the vanilla
kernel, even bonnie caused a couple of hiccups in xmms, with preempt
enabled, bonnie didn't affect xmms at all. all programs were run without
altering nice values at all.

For a workstation, I like the difference, my system is still usable even
with the load upwards of 14, without preempt, it's like looking at a
couple of screenshots. This is not something that I would recommend for
a server, but for a workstation, it works great.

Out of morbid curiousity, I ran a make -j bzImage to see how well this
would handle being driven into the ground. No oopsen, the OOM killer
worked great, killed everything that wasn't being used. The only prob is
that it hosed my console and killed my ssh daemon. oops ;) Sending a
sysrq-SAK and then a 3-finger-salute rebooted the system perfectly, no
fsck or anything.

I couldn't build that latency test for my system, so no results from it.
I haven't had a chance to look at it's source, so I'm not sure if I can
make it work here or not.

I'll keep up with your patches and keep you posted.

--
Gregory Finch


  parent reply	other threads:[~2001-09-09 18:58 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-08  5:22 grue
2001-09-08  5:47 ` Robert Love
2001-09-08 17:33   ` Arjan Filius
2001-09-08 18:22     ` safemode
2001-09-08 20:58     ` [SMP lock BUG?] " Roger Larsson
2001-09-08 22:18       ` Arjan Filius
2001-09-09 14:55       ` george anzinger
2001-09-09 22:25         ` Arjan Filius
2001-09-09  4:40     ` Robert Love
2001-09-09 17:09     ` Robert Love
2001-09-09 21:07       ` Arjan Filius
2001-09-09 21:26         ` Robert Love
2001-09-09 21:23       ` Arjan Filius
2001-09-09 21:37         ` Robert Love
2001-09-10  3:24           ` Daniel Phillips
2001-09-10  3:37             ` Jeremy Zawodny
2001-09-10  5:09           ` Robert Love
2001-09-10 18:25             ` Daniel Phillips
2001-09-10 21:29             ` Arjan Filius
2001-09-13 17:27               ` Robert Love
2001-09-14  7:30                 ` george anzinger
2001-09-14 15:01                 ` Robert Love
2001-09-11 19:47           ` Arjan Filius
2001-09-09 18:57   ` grue [this message]
2001-09-09 21:44     ` Robert Love
2001-09-11 22:53 Robert Love
2001-09-14  2:47 Dieter Nützel
     [not found] <200109150444.f8F4iEG19063@zero.tech9.net>
     [not found] ` <200109140302.f8E32LG13400@zero.tech9.net>
2001-09-14  4:35   ` Robert Love
2001-09-15  4:25     ` Dieter Nützel
2001-09-15  5:14     ` Robert Love
2001-09-18  4:06       ` Dieter Nützel
2001-09-18  8:35         ` Daniel Phillips
2001-09-18 18:18         ` Roger Larsson
2001-09-18 23:31         ` Robert Love
2001-09-20  6:40           ` Dieter Nützel
2001-09-18 23:31       ` Robert Love
     [not found] <Pine.LNX.4.33.0109140838040.21992-100000@sjoerd.sjoerdnet>
2001-09-14 15:04 ` Robert Love
2001-09-15  9:44   ` Arjan Filius
2001-09-15 10:38     ` Erik Mouw
2001-09-15 17:57     ` Robert Love
2001-09-15 19:18 Robert Love
2001-09-16  1:28 ` Daniel Phillips
2001-09-16  1:54   ` Daniel Phillips

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=20010909185727.586B1597C5@g-box.vf.shawcable.net \
    --to=grue@lakesweb.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rml@tech9.net \
    /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

all inboxes | Powered by JetHome®