All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Alberto Gonzalez <info@gnebu.es>
Cc: Paolo Ornati <ornati@fastwebnet.it>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Question about fair schedulers
Date: Sat, 23 Jun 2007 12:50:57 +0200	[thread overview]
Message-ID: <20070623105057.GD7070@1wt.eu> (raw)
In-Reply-To: <200706231245.30317.info@gnebu.es>

On Sat, Jun 23, 2007 at 12:45:30PM +0200, Alberto Gonzalez wrote:
> On Saturday 23 June 2007, Willy Tarreau wrote:
> 
> > > But the bottom line is that on a desktop, tasks should receive
> > > different -unfair- amounts of CPU time to work correctly. The "fair"
> > > concept still looks wrong to me.
> >
> > "fair" means what it means : stop starving some tasks for no apparent
> > reasons. If one task adjusts its priority, it can get more CPU than others,
> > but the distribution will still be fair according to the priorities.
> 
> Ok, this was the kind of technical explanation I was looking for, thanks.
> 
> > > Nicing tasks might not be hard at all, but expecting normal users to do
> > > so is not realistic. Either the scheduler or the applications should make
> > > these decisions for them (us).
> >
> > No, I cannot agree with you. The users have to solutions to start their
> > player: - typing "mplayer xxx.mpeg" on the command line ; then they can
> > prepend "nice" in front of it
> >
> >   - clicking on an icon in their windows-like window managers, which makes
> >     executes the command for them.
> >
> > If they decide to use the second solution, it means that the default
> > settings assigned to the icon should fit the application (that applies to
> > the nice value too). And if their distro ships with those pre-defined icons
> > with stupid priorities, they should complain to the distro vendor or switch
> > to another one. And if the window manager by itself does not make it easy
> > to adjust priorities when starting processes, it's poorly designed because
> > it is it and only it which forces the user to open a command line and
> > manually set "nice".
> >
> > So there are plenty of really transparent solutions for the user, but maybe
> > there are a lot of wrong tools and configurations...
> 
> Ok, so if I understand correctly, the problem I had in my simple test will be 
> solved by distributions once a fair scheduler goes into mainline?

No, there is no reason to wait for a fair scheduler at all. A *desktop* distro
*must* take process priorities into account, otherwise it's broken by design.
If you don't know where in your distro you can say "more CPU for the video"
and "less CPU for the encoder", then ask your vendor. It's something so much
basic and obvious that I cannot imagine not being supported. Even my mp3 player
script has been setting its prio for the last 8 years in order to avoid skips!

> This is 
> fine then. As long as someone (but not end users) takes care of giving the 
> right priority to tasks of different nature it should work fine.

Yes, it should.

Regards,
Willy


  reply	other threads:[~2007-06-23 10:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-22 22:07 Question about fair schedulers Alberto Gonzalez
2007-06-23  0:55 ` Kyle Moffett
2007-06-23  7:46   ` Alberto Gonzalez
2007-06-23 16:35     ` Kyle Moffett
2007-06-23 17:28       ` Alberto Gonzalez
2007-06-24 20:57         ` Jesper Juhl
2007-06-24 19:36     ` David Schwartz
2007-06-26 12:19     ` Helge Hafting
2007-06-27 12:39   ` Alberto Gonzalez
2007-06-23  7:06 ` Paolo Ornati
2007-06-23  8:01   ` Alberto Gonzalez
2007-06-23  8:23     ` Willy Tarreau
2007-06-23  9:18       ` Alberto Gonzalez
2007-06-23  9:28         ` Russell Harmon
2007-06-23 10:30         ` Willy Tarreau
2007-06-23 10:45           ` Alberto Gonzalez
2007-06-23 10:50             ` Willy Tarreau [this message]
2007-06-23 11:00               ` Alberto Gonzalez
2007-06-23 11:05                 ` Tom Spink
2007-06-23 11:26                   ` Alberto Gonzalez
2007-06-23 11:51                     ` Willy Tarreau
2007-06-27 20:28                     ` Bill Davidsen
2007-06-23 13:26     ` Paolo Ornati
2007-06-23 13:56       ` Alberto Gonzalez
2007-06-23 14:28         ` Paolo Ornati

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=20070623105057.GD7070@1wt.eu \
    --to=w@1wt.eu \
    --cc=info@gnebu.es \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ornati@fastwebnet.it \
    /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.