From: Andrew Morton <akpm@linux-foundation.org>
To: Dave Jones <davej@redhat.com>
Cc: tim.c.chen@linux.intel.com, linux-kernel@vger.kernel.org,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: Change in default vm_dirty_ratio
Date: Tue, 19 Jun 2007 21:44:07 -0700 [thread overview]
Message-ID: <20070619214407.dfff0ca6.akpm@linux-foundation.org> (raw)
In-Reply-To: <20070620042434.GC12096@redhat.com>
On Wed, 20 Jun 2007 00:24:34 -0400 Dave Jones <davej@redhat.com> wrote:
> On Mon, Jun 18, 2007 at 04:47:11PM -0700, Andrew Morton wrote:
>
> > Frankly, I find it very depressing that the kernel defaults matter. These
> > things are trivially tunable and you'd think that after all these years,
> > distro initscripts would be establishing the settings, based upon expected
> > workload, amount of memory, number and bandwidth of attached devices, etc.
>
> "This is hard, lets make it someone else's problem" shouldn't ever be the
> answer,
Bovine droppings. Nobody has even tried.
> especially if the end result is that we become even more
> dependant on bits of userspace running before the system becomes useful.
Cattle excreta. The kernel remains as it presently is. No less useful that it is
now.
> > Heck, there should even be userspace daemons which observe ongoing system
> > behaviour and which adaptively tune these things to the most appropriate
> > level.
> >
> > But nope, nothing.
>
> See the 'libtune' crack that people have been trying to get distros to
> adopt for a long time.
> If we need some form of adaptive behaviour, the kernel needs to be
> doing this monitoring/adapting, not some userspace daemon that may
> not get scheduled before its too late.
Userspace has just as much info as the kernel has and there is no latency
concern here.
> If the kernel can't get the defaults right, what makes you think
> userspace can do better ?
Because userspace can implement more sophisticated algorithms and is more
easily configured.
For example, userspace can take a hotplug event for the just-added
usb-storage device then go look up its IO characteristics in a database
and then apply that to the confgured policy. If the device was not found,
userspace can perform a test run to empirically measure that device's IO
characteristics and then record them in the database. I don't think we'll
be doing this in-kernel any time soon.
(And to preempt lkml-games: this is just an _example_. There are
others)
> Just as the kernel can't get
> "one size fits all" right, there's no silver bullet just by clicking
> "this is a database server" button to have it configure random
> sysctls etc. These things require thought and planning that
> daemons will never get right in every case. And when they get
> it wrong, the results can be worse than the stock defaults.
>
> libtune is the latest in a series of attempts to do this dynamic
> runtime adjustment (hell, I even started such a project myself
> back circa 2000 which thankfully never really took off).
> It's a bad idea that just won't die.
>
So libtune is the only possible way of implementing any of this?
If choosing the optimum settings cannot be done in userspace then it sure
as heck cannot be done in-kernel.
Anyway, this is all arse-about. What is the design? What algorithms
do we need to implement to do this successfully? Answer me that, then
we can decide upon these implementation details.
next prev parent reply other threads:[~2007-06-20 4:45 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-18 21:14 Change in default vm_dirty_ratio Tim Chen
2007-06-18 23:47 ` Andrew Morton
2007-06-19 0:06 ` Linus Torvalds
2007-06-19 0:09 ` Arjan van de Ven
2007-06-19 18:41 ` John Stoffel
2007-06-19 19:04 ` Linus Torvalds
2007-06-19 19:06 ` Linus Torvalds
2007-06-19 22:33 ` David Miller
2007-06-19 19:57 ` Andi Kleen
2007-06-20 4:24 ` Dave Jones
2007-06-20 4:44 ` Andrew Morton [this message]
2007-06-20 8:35 ` Peter Zijlstra
2007-06-20 8:58 ` Andrew Morton
2007-06-20 9:14 ` Jens Axboe
2007-06-20 9:19 ` Peter Zijlstra
2007-06-20 9:20 ` Jens Axboe
2007-06-20 9:43 ` Peter Zijlstra
2007-06-21 22:53 ` Matt Mackall
2007-06-21 23:08 ` Linus Torvalds
2007-06-23 18:23 ` Peter Zijlstra
2007-06-24 16:40 ` Linus Torvalds
2007-06-25 0:15 ` Peter Zijlstra
2007-06-20 9:19 ` Peter Zijlstra
2007-06-21 16:54 ` Mark Lord
2007-06-21 16:55 ` Peter Zijlstra
2007-06-20 17:17 ` Linus Torvalds
2007-06-20 18:12 ` Arjan van de Ven
2007-06-20 18:28 ` Linus Torvalds
2007-06-21 12:37 ` Nadia Derbey
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=20070619214407.dfff0ca6.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=tim.c.chen@linux.intel.com \
--cc=torvalds@linux-foundation.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