public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ed Sweetman <ed.sweetman@wmich.edu>
To: Randy Hron <rwhron@earthlink.net>
Cc: Andrew Morton <akpm@zip.com.au>,
	linux-kernel@vger.kernel.org, marcelo@conectiva.com.br
Subject: Re: Linux 2.4.19-pre5
Date: 30 Mar 2002 18:48:35 -0500	[thread overview]
Message-ID: <1017532120.641.75.camel@psuedomode> (raw)
In-Reply-To: <E16rRCX-00068U-00@avocet.prod.itd.earthlink.net>

[-- Attachment #1: Type: text/plain, Size: 1928 bytes --]

Due to evolution's really cool way of wrapping my emails. . i'll attach
the results.   

In this test I wanted to see this lag.  So i switched between virtual
desktops (i have 5) and used irc (eterm + epic).   What i saw was lower
priority (meaning processes with bigger nice values) at one specific
spot in the test would stop responding but all processes at the same
priority level would continue merrily.  I'd say about 5/6 of the way
through the test is where the lower priority processes would stop
responding for a couple seconds.  But they revived pretty quickly, only
paused my typing for a couple moments.  I failed to see any lag at all
during the entire test on like-wise prioritized processes.  I wouldn't
have even known i was running the test if my cpu temp wasn't climbing so
high and the load wasn't 256 on procmeter3.  


As for the throughput debate that always follows the preempt kernel.  I
think it really depends on the kind of io you're doing.  It really
depends on what the program is trying to do with it's io.  
Programs that want to throttle and like to do that sequentially,
probably wont appretiate you stopping it and reading some other part of
the disk for a bit and have it have to go back to where it stopped. 
Almost no userland non-monolithic database apps actually do something
like that.  None that i've come into contact with.  But you choose what
works for your workload.   if i'm running a app that wants control over
the io to itself, i run it with a higher priority than other processes
and you've basically taken away the "preemptiveness" factor and you get
normal kernel performance (theoretically).  seems logical.   

Anyway I digress.   I mean to get into the latency aspect.  Sequential
writes is scary but that's to be expected on ext3.  Random reads is a
concern though.   It shouldn't be that high.  although it was high in
all the tests i ran compared to the other three.    

[-- Attachment #2: ed_tiotest.text --]
[-- Type: text/plain, Size: 2057 bytes --]

Run #2: /usr/bin/tiotest -t 256 -f 8 -r 15 -b 4096 -d . -T    

File size in megabytes, Blk Size in bytes. 
Read, write, and seek rates in MB/sec. 
Latency in milliseconds.
Percent of requests that took longer than 2 and 10 seconds.

Sequential Reads
                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU
Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff
---------------------------- ------ ----- ---  ------------------------------------------------------------
2.4.19-pre4-ac3-preempt       2048  4096  256    9.46 5.271%   181.668    30992.77   3.60280  0.05836   179

Random Reads
                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU
Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff
---------------------------- ------ ----- ---  ------------------------------------------------------------
2.4.19-pre4-ac3-preempt       2048  4096  256    0.67 0.980%  2446.793    14462.86  39.66145  0.00000    68

Sequential Writes
                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU
Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff
---------------------------- ------ ----- ---  ------------------------------------------------------------
2.4.19-pre4-ac3-preempt       2048  4096  256    5.36 5.029%   160.584   209853.98   0.42915  0.37536   107

Random Writes
                              File  Blk   Num                    Avg       Maximum     Lat%     Lat%    CPU
Kernel                        Size  Size  Thr   Rate  (CPU%)   Latency     Latency      >2s     >10s    Eff
---------------------------- ------ ----- ---  ------------------------------------------------------------
2.4.19-pre4-ac3-preempt       2048  4096  256    0.67 0.533%     0.047        4.50   0.00000  0.00000   125

  reply	other threads:[~2002-03-30 23:49 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-03-30 18:53 Linux 2.4.19-pre5 rwhron
2002-03-30 19:49 ` Andrew Morton
2002-03-30 21:33   ` Randy Hron
2002-03-30 21:42     ` Ed Sweetman
2002-03-30 22:25       ` Randy Hron
2002-03-30 23:48         ` Ed Sweetman [this message]
2002-03-31 12:42           ` Randy Hron
2002-03-31 20:05             ` Ed Sweetman
2002-03-31 23:11               ` Randy Hron
2002-03-31  6:52   ` Andrew Morton
2002-04-01  0:36     ` Andrea Arcangeli
2002-04-01  1:24   ` Andrea Arcangeli
  -- strict thread matches above, loose matches on Subject: below --
2002-04-04  9:08 Tom Holroyd
2002-04-04 19:28 ` Marcelo Tosatti
2002-04-05  4:13   ` Tom Holroyd
2002-04-16 14:49     ` Andrea Arcangeli
2002-04-17  1:22       ` Tom Holroyd
2002-03-29 21:47 Marcelo Tosatti
2002-03-30 20:40 ` Michal Jaegermann
2002-03-30 23:34   ` Keith Owens
2002-03-31  1:41     ` Michal Jaegermann
2002-04-04 19:50 ` Adrian Bunk
2002-04-04 21:41   ` Marcelo Tosatti

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=1017532120.641.75.camel@psuedomode \
    --to=ed.sweetman@wmich.edu \
    --cc=akpm@zip.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo@conectiva.com.br \
    --cc=rwhron@earthlink.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