public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: DaMouse <damouse@zero10.demon.co.uk>
To: linux-kernel@vger.kernel.org
Subject: Re: Autotune swappiness01
Date: Mon, 26 Jul 2004 22:29:56 +0100	[thread overview]
Message-ID: <410577D4.1010800@zero10.demon.co.uk> (raw)

Perhaps the answer is a CONFIG_USERCONFIG or similar like in the car scenario,
those who like to take tools with them to fiddle and those who just like to drive.

-DaMouse

Previous Messages:

On Monday 26 of July 2004 20:45, Adam Kropelin wrote:
> On Mon, Jul 26, 2004 at 03:53:09PM +0200, R. J. Wysocki wrote:
> > On Monday 26 of July 2004 13:47, Nick Piggin wrote:
> > > Con Kolivas wrote:
> > > > Nick Piggin wrote:
> > > >> Con Kolivas wrote:
> > > >>> In my ideal, nonsensical, impossible to obtain world we have an
> > > >>> autoregulating operating system that doesn't need any knobs.
> > > >>
> > > >> Some thinks are fundamental tradeoffs that can't be autotuned.
> > > >>
> > > >> Latency vs throughput comes up in a lot of places, eg. timeslices.
> > > >>
> > > >> Maximum throughput via effective use of swap, versus swapping as
> > > >> a last resort may be another.
> > > >
> > > > As I said... it was ideal, nonsensical, and impossible. Doesn't sound
> > > > like you're arguing with me.
> > >
> > > No, you're right. My ideal operating system knows what the user
> > > wants too ;)
> >
> > Well, what I hate about various computer programs is that they seem to
> > assume to know what I (the USER) want and they don't let me do anything
> > else that they "know" what I should/would do. ;-)
> >
> > > Most of the time though, you are right. The quality/desirability of an
> > > implementation will be inversely proportional to the number of knobs
> > > sticking out of it (with bonus points for those that are meaningful to
> > > 2 people on the planet).
> >
> > Can you please tell me why you think that the least tunable
> > implementation should be the best/most desirable one?  I always prefer
> > the most tunable implementations which is quite opposite to what you have
> > said, but this is my personal opinion, of course.
>
> The implementation with the least *need* for tuning is the most
> desirable. I, for one, don't care if there are a dozen knobs as long as
> 99% of users don't have to touch them. But if common usage scenarios
> require turning knobs to get reasonable performance, the algorithm is
> lacking.

I agree in 100%.

> Thanks to fuel injection and engine management I can drive from LA to
> Denver and not need to tweak my carburator half way up the Rockies.
> I've given up some chances for tuning, but overall I'm better off. If
> you want to stick a trimpot or ten out the side of the engine management
> computer so true gearheads can tweak another couple HP or MPG out of the
> engine, great. But don't expect me to fiddle with it every time driving
> conditions change; it's not an excuse to make the management algorithms
> inadequate for common driving patterns.

I didn't mean that.  Actually, I was trying to say that an additional "knob" 
(or "knobs") might be useful in determining the "common settings" acceptable 
for the 99% of users.  Then, it could be "hidden" (which I wouldn't do, but 
well ...).
Yours,
rjw


             reply	other threads:[~2004-07-26 21:30 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-26 21:29 DaMouse [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-07-26 14:52 Autotune swappiness01 Martin Knoblauch
2004-07-26  0:25 [PATCH][2.6.8-rc1-mm1] " Con Kolivas
2004-07-26  0:36 ` Andrew Morton
2004-07-26  0:43   ` Con Kolivas
2004-07-26  0:48     ` Andrew Morton
2004-07-26  1:01       ` Con Kolivas
2004-07-26  1:09         ` Con Kolivas
2004-07-26  8:52           ` R. J. Wysocki
2004-07-26  9:31             ` Con Kolivas
2004-07-26 10:34               ` R. J. Wysocki
2004-07-26 10:29                 ` Con Kolivas
2004-07-26 10:54                   ` R. J. Wysocki
2004-07-26 11:03                     ` Con Kolivas
2004-07-26 11:13                       ` Nick Piggin
2004-07-26 11:17                         ` Con Kolivas
2004-07-26 11:47                           ` Nick Piggin
2004-07-26 13:53                             ` R. J. Wysocki
2004-07-26 18:45                               ` Adam Kropelin
2004-07-26 18:53                                 ` R. J. Wysocki
2004-07-26 17:55                     ` Gerrit Huizenga
2004-07-26 20:29     ` Joel Becker
2004-07-26 20:42       ` Andrew Morton
2004-07-26 22:58         ` Con Kolivas
2004-07-27  0:52           ` Clemens Schwaighofer
2004-07-27  1:09             ` Andrew Morton
2004-07-27  1:17               ` Clemens Schwaighofer
2004-07-27  2:03                 ` Tim Connors
2004-07-27  2:43                   ` Con Kolivas
2004-07-27  3:02                     ` Tim Connors
2004-07-27  3:43                       ` Clemens Schwaighofer
2004-07-27  3:47                       ` Joel Becker
2004-07-27 15:32                         ` William Lee Irwin III
2004-07-27  3:41                   ` Clemens Schwaighofer

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=410577D4.1010800@zero10.demon.co.uk \
    --to=damouse@zero10.demon.co.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox