From: Bart Samwel <bart@samwel.tk>
To: Timothy Miller <miller@techsource.com>
Cc: Paul Jackson <pj@sgi.com>,
vonbrand@inf.utfsm.cl, nickpiggin@yahoo.com.au,
jgarzik@pobox.com, Andrew Morton <akpm@osdl.org>,
brettspamacct@fastclick.com, linux-kernel@vger.kernel.org
Subject: Re: ~500 megs cached yet 2.6.5 goes into swap hell
Date: Fri, 30 Apr 2004 14:31:34 +0200 [thread overview]
Message-ID: <1083328293.2204.53.camel@samwel.tk> (raw)
In-Reply-To: <40918AD2.9060602@techsource.com>
On Fri, 2004-04-30 at 01:08, Timothy Miller wrote:
> Agreed. And this is why I suggested not adding another knob but rather
> going with the existing nice value.
>
> Mind you, this shouldn't necessarily be done without some kind of
> experimentation. Put two knobs in the kernel and try varying them to
> each other to see what sorts of jobs, if any, would benefit in a
> disparity between cpu-nice and io-nice. If there IS a significant
> difference, then add the extra knob. If there isn't, then don't.
Thought experiment: what would happen when you set the hypothetical
cpu-nice and io-nice knobs very differently?
* cpu-nice 20, io-nice -20: Read I/O will finish immediately, but then
the process will have to wait for ages to get a CPU slice to process the
data, so why would you want to read it so quickly? The process can do as
much write I/O as it wants, but why is it not okay to take ages to write
the data if it's okay to take ages to produce it?
* cpu-nice -20, io-nice 20: Read I/O will take ages, but once the data
gets there, the processor is immediately taken to process the data as
fast as possible. If it was okay to take ages to read the data, why
would you want to process it as soon as you can? It makes some sense for
write I/O though: produce data as fast as the other processes will allow
you to write it. But if you're going to hog the CPU completely, why give
other processes the chance to do a lot of I/O while they don't get the
CPU time to submit any I/O? Going for a smaller difference makes more
sense.
As far as I can tell, giving the knobs very different values doesn't
make much sense. The same arguments go for medium-sized differences. And
if we're going to give the knobs only *slightly* different values, we
might as well make them the same. If we really need cpu-nice = 0 and
io-nice = 3 somewhere, then I think that's a sign of a kernel problem,
where the kernel's various nice-knobs aren't calibrated correctly to
result in the same amount of "niceness" when they're set to the same
value. And cpu-nice = io-nice = 3 would probably have about the same
effect.
BTW, if there *are* going to be more knobs, I suggest adding
"memory-nice" as well. :) If you set memory-nice to 20, then the process
will not kick out much memory from other processes (it will require more
I/O -- but that can be throttled using io-nice). If you set memory-nice
to -20, then the process will kick out the memory of all other processes
if it needs to.
--Bart
next prev parent reply other threads:[~2004-04-30 12:32 UTC|newest]
Thread overview: 128+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-28 21:27 ~500 megs cached yet 2.6.5 goes into swap hell Brett E.
2004-04-29 0:01 ` Andrew Morton
2004-04-29 0:10 ` Jeff Garzik
2004-04-29 0:21 ` Nick Piggin
2004-04-29 0:50 ` Wakko Warner
2004-04-29 0:53 ` Jeff Garzik
2004-04-29 0:54 ` Nick Piggin
2004-04-29 1:51 ` Tim Connors
2004-04-29 21:45 ` Denis Vlasenko
2004-04-29 0:58 ` Marc Singer
2004-04-29 3:48 ` Nick Piggin
2004-04-29 4:20 ` Marc Singer
2004-04-29 4:26 ` Nick Piggin
2004-04-29 14:49 ` Marc Singer
2004-04-30 4:08 ` Nick Piggin
2004-04-30 22:31 ` Marc Singer
2004-04-29 6:38 ` William Lee Irwin III
2004-04-29 7:36 ` Russell King
2004-04-29 10:44 ` Nick Piggin
2004-04-29 11:04 ` Russell King
2004-04-29 14:52 ` Marc Singer
2004-04-29 20:01 ` Horst von Brand
2004-04-29 20:18 ` Martin J. Bligh
2004-04-29 20:33 ` David B. Stevens
2004-04-29 22:42 ` Steve Youngs
2004-04-29 20:36 ` Paul Jackson
2004-04-29 21:19 ` Andrew Morton
2004-04-29 21:34 ` Paul Jackson
2004-04-29 21:57 ` Andrew Morton
2004-04-29 22:18 ` Paul Jackson
2004-04-30 0:04 ` Andy Isaacson
2004-04-30 0:32 ` Andrew Morton
2004-04-30 0:54 ` Paul Jackson
2004-04-30 5:38 ` Andy Isaacson
2004-04-30 6:00 ` Nick Piggin
2004-04-30 7:52 ` Jeff Garzik
2004-04-30 8:02 ` Andrew Morton
2004-04-30 8:09 ` Jeff Garzik
2004-05-06 13:08 ` Pavel Machek
2004-05-07 15:53 ` Hugh Dickins
2004-05-07 16:57 ` Pavel Machek
2004-05-07 17:30 ` Timothy Miller
2004-05-07 17:43 ` Hugh Dickins
2004-05-07 17:48 ` Mark Frazer
2004-05-12 17:52 ` Rob Landley
2004-05-17 20:16 ` Hugh Dickins
2004-04-29 21:38 ` Timothy Miller
2004-04-29 21:47 ` Paul Jackson
2004-04-29 22:18 ` Timothy Miller
2004-04-29 22:46 ` Paul Jackson
2004-04-29 23:08 ` Timothy Miller
2004-04-30 12:31 ` Bart Samwel [this message]
2004-04-30 15:35 ` Clay Haapala
2004-04-30 15:44 ` Bart Samwel
2004-04-30 22:11 ` Paul Jackson
2004-04-30 3:37 ` Tim Connors
2004-04-30 5:15 ` Nick Piggin
2004-04-30 6:20 ` Tim Connors
2004-04-30 6:34 ` Nick Piggin
2004-04-30 7:05 ` Tim Connors
2004-04-30 7:15 ` Nick Piggin
2004-04-30 9:18 ` Re[2]: " vda
2004-04-30 9:33 ` Arjan van de Ven
2004-04-30 11:33 ` Denis Vlasenko
2004-04-30 16:19 ` Timothy Miller
2004-04-29 0:49 ` Brett E.
2004-04-29 1:00 ` Andrew Morton
2004-04-29 1:24 ` Jeff Garzik
2004-04-29 1:40 ` Andrew Morton
2004-04-29 1:47 ` Rik van Riel
2004-04-29 18:14 ` Adam Kropelin
2004-04-30 3:17 ` Tim Connors
2004-04-29 2:19 ` Tim Connors
2004-04-29 16:24 ` Martin J. Bligh
2004-04-29 16:36 ` Chris Friesen
2004-04-29 16:56 ` Martin J. Bligh
2004-04-29 1:30 ` Paul Mackerras
2004-04-29 1:31 ` Paul Mackerras
2004-04-29 1:53 ` Andrew Morton
2004-04-29 2:40 ` Andrew Morton
2004-04-29 2:58 ` Paul Mackerras
2004-04-29 3:09 ` Andrew Morton
2004-04-29 3:14 ` William Lee Irwin III
2004-04-29 6:12 ` Benjamin Herrenschmidt
2004-04-29 6:22 ` Andrew Morton
2004-04-29 6:25 ` Benjamin Herrenschmidt
2004-04-29 6:31 ` William Lee Irwin III
2004-04-29 16:50 ` Martin J. Bligh
2004-04-29 3:57 ` Nick Piggin
2004-04-29 14:29 ` Rik van Riel
2004-04-30 3:00 ` Nick Piggin
2004-04-30 12:50 ` Rik van Riel
2004-04-30 13:07 ` Nick Piggin
2004-04-30 13:18 ` Nikita Danilov
2004-04-30 13:39 ` Nick Piggin
2004-04-29 1:46 ` Rik van Riel
2004-04-29 1:57 ` Andrew Morton
2004-04-29 2:29 ` Marc Singer
2004-04-29 2:35 ` Andrew Morton
2004-04-29 3:10 ` Marc Singer
2004-04-29 3:19 ` Andrew Morton
2004-04-29 4:13 ` Marc Singer
2004-04-29 4:33 ` Andrew Morton
2004-04-29 14:45 ` Marc Singer
2004-04-29 16:51 ` Andy Isaacson
2004-04-29 20:42 ` Andrew Morton
2004-04-29 22:27 ` Andy Isaacson
2004-04-29 23:19 ` Andrew Morton
2004-04-30 0:14 ` Lincoln Dale
2004-04-29 8:02 ` Wichert Akkerman
2004-04-29 14:25 ` Marcelo Tosatti
2004-04-29 14:27 ` Wichert Akkerman
2004-04-29 2:41 ` Rik van Riel
2004-04-29 2:43 ` Andrew Morton
2004-04-29 1:41 ` Tim Connors
2004-04-29 9:43 ` Helge Hafting
2004-04-29 14:48 ` Marc Singer
2004-04-29 0:44 ` Brett E.
2004-04-29 1:13 ` Andrew Morton
2004-04-29 1:29 ` Brett E.
2004-04-29 18:05 ` Brett E.
2004-04-29 18:32 ` William Lee Irwin III
2004-04-29 20:47 ` Brett E.
2004-04-29 0:04 ` Brett E.
2004-04-29 0:13 ` Jeff Garzik
2004-04-29 0:43 ` Nick Piggin
2004-04-29 13:51 ` Horst von Brand
2004-04-29 18:32 ` Brett E.
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=1083328293.2204.53.camel@samwel.tk \
--to=bart@samwel.tk \
--cc=akpm@osdl.org \
--cc=brettspamacct@fastclick.com \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=miller@techsource.com \
--cc=nickpiggin@yahoo.com.au \
--cc=pj@sgi.com \
--cc=vonbrand@inf.utfsm.cl \
/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