public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Con Kolivas <kernel@kolivas.org>
To: Al Boldi <a1426z@gawab.com>
Cc: linux-kernel@vger.kernel.org, linux-smp@vger.kernel.org
Subject: Re: [RFC] sched.c : procfs tunables
Date: Sat, 1 Apr 2006 00:44:08 +1000	[thread overview]
Message-ID: <200604010044.09185.kernel@kolivas.org> (raw)
In-Reply-To: <200603311723.49049.a1426z@gawab.com>

On Saturday 01 April 2006 00:23, Al Boldi wrote:
> Proper scheduling in a multi-tasking environment is critical to the success
> of a desktop OS.  Linux, being mainly a server OS, is currently tuned to
> scheduling defaults that may be appropriate only for the server scenario.
>
> To enable Linux to play an effective role on the desktop, a more flexible
> approach is necessary.  An approach that would allow the end-User the
> freedom to adjust the OS to the specific environment at hand.
>
> So instead of forcing a one-size fits all approach on the end-User, would
> not exporting sched.c tunables to the procfs present a flexible approach to
> the scheduling dilemma?
>
> All comments that have a vested interest in enabling Linux on the desktop
> are most welcome, even if they describe other/better/smarter approaches.

None of the current "tunables" have easily understandable heuristics. Even 
those that appear to be obvious, like timselice, are not. While exporting 
tunables is not a bad idea, exporting tunables that noone understands is not 
really helpful. Even with heavy documentation, changes are not immediately 
predictable, and parts of the scheduler "know" about the default tuning 
values and they'd be broken by modifying them. Other scheduler designs, or 
more infrastructure on the current one (like what Mike's working on) might 
make some more obvious tunables. I've already discussed what I think in that 
regard too on a similar email thread. Exporting them also incurs a not 
insignificant cost.

Cheers,
Con

  reply	other threads:[~2006-03-31 14:44 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-31 14:23 [RFC] sched.c : procfs tunables Al Boldi
2006-03-31 14:44 ` Con Kolivas [this message]
2006-04-03 11:59   ` Al Boldi
2006-04-03 12:21     ` Con Kolivas
2006-04-04 13:27       ` Al Boldi
2006-04-07  2:47         ` Bill Davidsen
2006-04-03 12:43     ` Mike Galbraith
2006-04-01  2:49 ` Mike Galbraith
2006-04-07  2:57 ` Bill Davidsen

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=200604010044.09185.kernel@kolivas.org \
    --to=kernel@kolivas.org \
    --cc=a1426z@gawab.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-smp@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