From: Bill Davidsen <davidsen@tmr.com>
To: linux-kernel@vger.kernel.org
Subject: Re: swapping and the value of /proc/sys/vm/swappiness
Date: Thu, 09 Sep 2004 12:26:11 -0400 [thread overview]
Message-ID: <chpvpj$3vs$1@gatekeeper.tmr.com> (raw)
In-Reply-To: <50520000.1094682042@flay>
Martin J. Bligh wrote:
>>>I really don't see any point in pushing the self-tuning of the kernel out
>>>into userspace. What are you hoping to achieve?
>>
>>Well your own words explain it, I think. "it's all dependant on the workload",
>>which means that only the user knows what he is going to do with the machine
>>and that the kernel doesn't knows that, so the algoritms built in the kernel
>>may be "not perfect" in their auto-tuning job. The point would be to
>>be able to take decisions the kernel can't take because userspace would
>>know better how the system should behave, say stupids things like "I want
>>to have this set of tunables which make compile jobs 0.01% faster at 12:00
>>because at that time a cron job autocompiles cvs snapshots of some project,
>>and at 6:00 those jobs have already finished so at that time I want a set
>>of tunables optimized for my everyday desktop work which make everthing 0.01%
>>slower but the system feels a 5% more reponsive". (well, for that a shell script
>>is enought) Kernel however could try to adapt itself to those changes, and do
>>it well...I don't really know. This came to my mind when I was thinking about
>>irqbalance case, which was somewhat similar, I also remember a discussion
>>about a "ktuned" in the mailing lists...I guess it's a matter of coding it
>>and get some numbers :-/
>
>
> Oh, I see what you mean. I think we're much better off sticking the mechanism
> for autotuning stuff in the kernel - if we want to feed in policy from
> userspace (which 99.9% of people will never do), it can be through such
> things as /proc/sys/vm/swapiness ... that could just fix them statically
> if people insisted on such things.
>
> Having the kernel do something sensible by default is what we aim for ...
> overrides still are possible if the sysadmin really thinks they're smarter ;-)
Don't need to be smarter, just to know more about program behaviour and
desired system response than the o/s. Think of it as providing more
information to the o/s and letting the o/s autotune with the additional
information if that makes you feel better ;-)
The only tune I really want, and I patched it in 2.4.18 or so, is the
ability to reserve some memory which will never be used for anything but
program pages. Or some way to stop a program making a single pass
through a large file (80GB) from pushing programs out of memory. I'm
watching that now as I read the list, vmstat says si/so are about 800
each, on a system which runs at zero otherwise.
I'm going to look at capabilities when I get that mythical free time,
and see if I can let a few programs lock their ass in memory, having
60-80% of RAM dedicated to once-read pages is silly.
Sorry for the rant, but this is the single most common problem I see
with performance.
--
-bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
next prev parent reply other threads:[~2004-09-09 16:26 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-06 19:11 swapping and the value of /proc/sys/vm/swappiness Ray Bryant
2004-09-06 20:10 ` Andrew Morton
2004-09-06 20:10 ` Andrew Morton
2004-09-06 21:22 ` Ray Bryant
2004-09-06 21:22 ` Ray Bryant
2004-09-06 21:36 ` Andrew Morton
2004-09-06 21:36 ` Andrew Morton
2004-09-06 22:37 ` William Lee Irwin III
2004-09-06 22:37 ` William Lee Irwin III
2004-09-06 23:51 ` Nick Piggin
2004-09-06 23:51 ` Nick Piggin
2004-09-07 0:31 ` Ray Bryant
2004-09-07 0:31 ` Ray Bryant
2004-09-06 22:48 ` William Lee Irwin III
2004-09-06 22:48 ` William Lee Irwin III
2004-09-06 23:09 ` Con Kolivas
2004-09-06 23:09 ` Con Kolivas
2004-09-06 23:27 ` Andrew Morton
2004-09-06 23:27 ` Andrew Morton
2004-09-06 23:34 ` Con Kolivas
2004-09-06 23:34 ` Con Kolivas
2004-09-07 0:03 ` Marcelo Tosatti
2004-09-07 0:03 ` Marcelo Tosatti
2004-09-07 1:34 ` Con Kolivas
2004-09-07 1:34 ` Con Kolivas
2004-09-07 10:38 ` Nick Piggin
2004-09-07 10:38 ` Nick Piggin
2004-09-07 10:56 ` Con Kolivas
2004-09-08 16:45 ` Marcelo Tosatti
2004-09-08 16:45 ` Marcelo Tosatti
2004-09-09 1:12 ` Con Kolivas
2004-09-07 17:03 ` Ray Bryant
2004-09-07 17:03 ` Ray Bryant
2004-09-07 21:20 ` Marcelo Tosatti
2004-09-07 21:20 ` Marcelo Tosatti
2004-09-08 2:18 ` Marcelo Tosatti
2004-09-08 2:18 ` Marcelo Tosatti
2004-09-08 14:20 ` Ray Bryant
2004-09-08 16:54 ` Marcelo Tosatti
2004-09-08 16:54 ` Marcelo Tosatti
2004-09-08 19:35 ` Ray Bryant
2004-09-08 19:35 ` Ray Bryant
2004-09-08 19:30 ` Marcelo Tosatti
2004-09-08 19:30 ` Marcelo Tosatti
2004-09-09 3:06 ` Ray Bryant
2004-09-09 3:06 ` Ray Bryant
2004-09-09 2:14 ` Marcelo Tosatti
2004-09-09 2:14 ` Marcelo Tosatti
2004-09-09 14:21 ` Ray Bryant
2004-09-09 14:21 ` Ray Bryant
2004-09-09 3:09 ` William Lee Irwin III
2004-09-09 3:09 ` William Lee Irwin III
2004-09-09 14:16 ` Ray Bryant
2004-09-09 17:23 ` William Lee Irwin III
2004-09-09 17:23 ` William Lee Irwin III
2004-09-28 1:54 ` Ray Bryant
2004-09-28 3:36 ` Nick Piggin
2004-09-28 3:36 ` Nick Piggin
2004-09-29 0:36 ` Nick Piggin
2004-09-29 4:23 ` Ray Bryant
2004-09-29 4:23 ` Ray Bryant
2004-09-30 17:15 ` Ray Bryant
2004-09-30 17:15 ` Ray Bryant
2004-09-08 17:31 ` Martin J. Bligh
2004-09-08 17:31 ` Martin J. Bligh
2004-09-08 18:04 ` Rik van Riel
2004-09-08 18:04 ` Rik van Riel
2004-09-08 19:50 ` Diego Calleja
2004-09-08 19:50 ` Diego Calleja
2004-09-08 21:10 ` Martin J. Bligh
2004-09-08 21:10 ` Martin J. Bligh
2004-09-08 21:55 ` Diego Calleja
2004-09-08 21:55 ` Diego Calleja
2004-09-08 22:20 ` Martin J. Bligh
2004-09-08 22:20 ` Martin J. Bligh
2004-09-08 23:22 ` Rik van Riel
2004-09-08 23:22 ` Rik van Riel
2004-09-09 16:26 ` Bill Davidsen [this message]
2004-09-08 22:28 ` Alan Cox
2004-09-08 22:28 ` Alan Cox
2004-09-08 23:42 ` Martin J. Bligh
2004-09-08 23:42 ` Martin J. Bligh
2004-09-08 19:54 ` Ray Bryant
2004-09-08 19:54 ` Ray Bryant
2004-09-08 15:19 ` Ray Bryant
2004-09-08 15:19 ` Ray Bryant
2004-09-14 18:31 ` Florin Andrei
2004-09-14 20:15 ` Marcelo Tosatti
2004-09-14 22:53 ` Con Kolivas
2004-09-14 21:41 ` Marcelo Tosatti
2004-09-15 0:22 ` Con Kolivas
2004-09-16 18:50 ` Marcelo Tosatti
2004-09-17 0:22 ` Con Kolivas
2004-09-15 16:54 ` Florin Andrei
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='chpvpj$3vs$1@gatekeeper.tmr.com' \
--to=davidsen@tmr.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.