All of lore.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 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.