From: "Martin J. Bligh" <mbligh@aracnet.com>
To: Diego Calleja <diegocg@teleline.es>
Cc: riel@redhat.com, raybry@sgi.com, marcelo.tosatti@cyclades.com,
kernel@kolivas.org, akpm@osdl.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, piggin@cyberone.com.au
Subject: Re: swapping and the value of /proc/sys/vm/swappiness
Date: Wed, 08 Sep 2004 15:20:42 -0700 [thread overview]
Message-ID: <50520000.1094682042@flay> (raw)
In-Reply-To: <20040908235503.3f01523a.diegocg@teleline.es>
>> 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 ;-)
M.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-09-08 22:20 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-06 19:11 Ray Bryant
2004-09-06 20:10 ` Andrew Morton
2004-09-06 21:22 ` Ray Bryant
2004-09-06 21:36 ` Andrew Morton
2004-09-06 22:37 ` William Lee Irwin III
2004-09-06 23:51 ` Nick Piggin
2004-09-07 0:31 ` Ray Bryant
2004-09-06 22:48 ` William Lee Irwin III
2004-09-06 23:09 ` Con Kolivas
2004-09-06 23:27 ` Andrew Morton
2004-09-06 23:34 ` Con Kolivas
2004-09-07 0:03 ` Marcelo Tosatti
2004-09-07 1:34 ` Con Kolivas
2004-09-07 10:38 ` Nick Piggin
2004-09-07 10:56 ` Con Kolivas
2004-09-08 16:45 ` Marcelo Tosatti
2004-09-09 1:12 ` Con Kolivas
2004-09-07 17:03 ` Ray Bryant
2004-09-07 21:20 ` 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 19:35 ` Ray Bryant
2004-09-08 19:30 ` Marcelo Tosatti
2004-09-09 3:06 ` Ray Bryant
2004-09-09 2:14 ` Marcelo Tosatti
2004-09-09 14:21 ` Ray Bryant
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-28 1:54 ` Ray Bryant
2004-09-28 3:36 ` Nick Piggin
2004-09-29 0:36 ` Nick Piggin
2004-09-29 4:23 ` Ray Bryant
2004-09-30 17:15 ` Ray Bryant
2004-09-08 17:31 ` Martin J. Bligh
2004-09-08 18:04 ` Rik van Riel
2004-09-08 19:50 ` Diego Calleja
2004-09-08 21:10 ` Martin J. Bligh
2004-09-08 21:55 ` Diego Calleja
2004-09-08 22:20 ` Martin J. Bligh [this message]
2004-09-08 23:22 ` Rik van Riel
2004-09-08 22:28 ` Alan Cox
2004-09-08 23:42 ` Martin J. Bligh
2004-09-08 19:54 ` Ray Bryant
2004-09-08 15:19 ` Ray Bryant
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=50520000.1094682042@flay \
--to=mbligh@aracnet.com \
--cc=akpm@osdl.org \
--cc=diegocg@teleline.es \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=piggin@cyberone.com.au \
--cc=raybry@sgi.com \
--cc=riel@redhat.com \
/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