From: Andrew Morton <andrewm@uow.edu.au>
To: Jonathan Morton <chromi@cyberspace.org>
Cc: lkml <linux-kernel@vger.kernel.org>, linux-mm@kvack.org
Subject: Re: VM Report was:Re: Break 2.4 VM in five easy steps
Date: Sat, 09 Jun 2001 12:36:24 +1000 [thread overview]
Message-ID: <3B218BA8.6A8C2EB0@uow.edu.au> (raw)
In-Reply-To: <Pine.LNX.4.21.0106081701300.2422-100000@freak.distro.conectiva>, <15137.15472.264539.290588@gargle.gargle.HOWL> <l0313032bb7471092da13@[192.168.239.105]>
Jonathan Morton wrote:
>
> [ Re-entering discussion after too long a day and a long sleep... ]
>
> >> There is the problem in terms of some people want pure interactive
> >> performance, while others are looking for throughput over all else,
> >> but those are both extremes of the spectrum. Though I suspect
> >> raw throughput is the less wanted (in terms of numbers of systems)
> >> than keeping interactive response good during VM pressure.
> >
> >And this raises a very very important point: raw throughtput wins
> >enterprise-like benchmarks, and the enterprise people are the ones who pay
> >most of hackers here. (including me and Rik)
>
> Very true. As well as the fact that interactivity is much harder to
> measure. The question is, what is interactivity (from the kernel's
> perspective)? It usually means small(ish) processes with intermittent
> working-set and CPU requirements. These types of process can safely be
> swapped out when not immediately in use, but the kernel has to be able to
> page them in quite quickly when needed. Doing that under heavy load is
> very non-trivial.
For the low-latency stuff, latency can be defined as
the worst-case time to schedule a userspace process in
response to an interrupt.
That metric is also appropriate in this case, (latency equals
interactivity), although here you don't need to be so fanatical
about the *worst case*. A few scheduling blips here are less
fatal.
I have tools to measure latency (aka interactivity). At
http://www.uow.edu.au/~andrewm/linux/schedlat.html#downloads
there is a kernel patch called `rtc-debug' which causes
the PC RTC to generate a stream of interrupts. A user-space
task called `amlat' responds to those interrupts and
reads the RTC device. The patched RTC driver can then
measure the elapsed time between the interrupt and the
read from userspace. Voila: latency.
When you close the RTC device (by killing amlat), the RTC
driver will print out a histogram of the latencies.
`amlat' at present gives itself SCHED_RR policy and
runs under mlockall() - for your testing you'll need
to delete those lines.
So. Simple apply rtc-debug, run `amlat' and kill it
when you've finished the workload.
The challenge will be to relate the latency histogram
to human-perceived interactivity. I'm not sure of
the best way of doing that. Perhaps monitor the 90th
percentile, and aim to keep it below 100 milliseconds.
Also, `amlat' should do a bit of disk I/O as well.
next prev parent reply other threads:[~2001-06-09 2:44 UTC|newest]
Thread overview: 106+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-06-05 22:19 Break 2.4 VM in five easy steps Derek Glidden
2001-06-05 23:38 ` Jeffrey W. Baker
2001-06-06 1:42 ` Russell Leighton
2001-06-06 7:14 ` Sean Hunter
2001-06-06 2:16 ` Andrew Morton
2001-06-06 3:19 ` Derek Glidden
2001-06-06 14:16 ` Disconnect
[not found] ` <3B1DEAC7.43DEFA1C@idb.hist.no>
2001-06-06 14:51 ` Derek Glidden
2001-06-06 21:34 ` Alan Cox
2001-06-09 8:07 ` Rik van Riel
2001-06-07 7:23 ` Helge Hafting
2001-06-07 16:56 ` Eric W. Biederman
2001-06-07 20:24 ` José Luis Domingo López
2001-06-06 4:03 ` Jeffrey W. Baker
2001-06-06 8:19 ` Xavier Bestel
2001-06-06 8:54 ` Sean Hunter
2001-06-06 9:57 ` Dr S.M. Huen
2001-06-06 10:06 ` DBs (ML)
2001-06-06 10:08 ` Vivek Dasmohapatra
2001-06-06 10:19 ` Lauri Tischler
2001-06-06 10:22 ` Sean Hunter
2001-06-06 10:48 ` Alexander Viro
2001-06-06 16:58 ` dean gaudet
2001-06-06 17:10 ` Remi Turk
2001-06-06 22:44 ` Kai Henningsen
2001-06-09 7:17 ` Rik van Riel
2001-06-06 16:47 ` dean gaudet
2001-06-06 17:17 ` Kurt Roeckx
2001-06-06 18:35 ` Dr S.M. Huen
2001-06-06 18:40 ` Mark Salisbury
2001-06-07 0:20 ` Mike A. Harris
2001-06-09 8:16 ` Rik van Riel
2001-06-09 8:57 ` Mike A. Harris
2001-06-07 21:31 ` Shane Nay
2001-06-07 20:00 ` Marcelo Tosatti
2001-06-07 21:55 ` Shane Nay
2001-06-07 20:29 ` Marcelo Tosatti
2001-06-07 23:29 ` VM Report was:Re: " Shane Nay
2001-06-08 1:18 ` Jonathan Morton
2001-06-08 12:50 ` Mike Galbraith
2001-06-08 14:19 ` Tobias Ringstrom
2001-06-08 16:51 ` Mike Galbraith
2001-06-08 19:09 ` Tobias Ringstrom
2001-06-09 4:36 ` Mike Galbraith
2001-06-08 15:51 ` John Stoffel
2001-06-08 17:01 ` Mike Galbraith
2001-06-09 3:34 ` Rik van Riel
2001-06-08 17:43 ` John Stoffel
2001-06-08 17:35 ` Marcelo Tosatti
2001-06-09 5:07 ` Mike Galbraith
2001-06-08 18:30 ` Mike Galbraith
2001-06-09 12:31 ` Zlatko Calusic
2001-06-08 20:58 ` John Stoffel
2001-06-08 20:04 ` Marcelo Tosatti
2001-06-08 23:44 ` Jonathan Morton
2001-06-09 2:36 ` Andrew Morton [this message]
2001-06-09 6:33 ` Mark Hahn
2001-06-09 3:43 ` Mike Galbraith
2001-06-09 4:05 ` Jonathan Morton
2001-06-09 5:09 ` Mike Galbraith
2001-06-06 10:04 ` Jonathan Morton
2001-06-06 11:16 ` Daniel Phillips
2001-06-06 13:58 ` Gerhard Mack
2001-06-08 4:56 ` C. Martins
2001-06-06 15:28 ` Richard Gooch
2001-06-06 15:42 ` Christian Bornträger
2001-06-06 15:57 ` Requirement: swap = RAM x 2.5 ?? Jeff Garzik
2001-06-06 18:42 ` Eric W. Biederman
2001-06-07 1:29 ` Jan Harkes
2001-06-06 16:12 ` Richard Gooch
2001-06-06 16:15 ` Jeff Garzik
2001-06-06 16:19 ` Richard Gooch
2001-06-06 16:53 ` Mike Galbraith
2001-06-06 17:05 ` Greg Hennessy
2001-06-06 17:14 ` Break 2.4 VM in five easy steps Ben Greear
2001-06-06 19:11 ` android
2001-06-07 0:27 ` Mike A. Harris
2001-06-06 9:16 ` Xavier Bestel
2001-06-06 9:25 ` Sean Hunter
2001-06-06 12:07 ` Jonathan Morton
2001-06-06 14:41 ` Derek Glidden
2001-06-06 20:29 ` José Luis Domingo López
2001-06-06 13:32 ` Eric W. Biederman
2001-06-06 14:41 ` Marc Heckmann
2001-06-06 14:51 ` Hugh Dickins
2001-06-06 7:47 ` Jonathan Morton
2001-06-06 13:08 ` Eric W. Biederman
2001-06-06 16:48 ` Jeffrey W. Baker
[not found] ` <m2lmn61ceb.fsf@sympatico.ca>
2001-06-06 14:37 ` Derek Glidden
2001-06-07 0:34 ` Mike A. Harris
2001-06-07 3:13 ` Miles Lane
2001-06-07 15:49 ` Derek Glidden
2001-06-07 19:06 ` Miles Lane
2001-06-09 5:57 ` Mike A. Harris
2001-06-06 18:59 ` Mike Galbraith
2001-06-06 19:39 ` Derek Glidden
2001-06-06 20:47 ` Linus Torvalds
2001-06-07 7:42 ` Eric W. Biederman
2001-06-07 8:11 ` Linus Torvalds
2001-06-07 8:54 ` Eric W. Biederman
2001-06-06 21:39 ` android
2001-06-06 22:08 ` Jonathan Morton
2001-06-06 22:27 ` android
2001-06-06 22:33 ` Antoine
2001-06-06 22:38 ` Robert Love
2001-06-06 22:40 ` Jonathan Morton
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=3B218BA8.6A8C2EB0@uow.edu.au \
--to=andrewm@uow.edu.au \
--cc=chromi@cyberspace.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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).