mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alberto Gonzalez <info@gnebu.es>
To: Kyle Moffett <mrmacman_g4@mac.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Question about fair schedulers
Date: Sat, 23 Jun 2007 19:28:22 +0200	[thread overview]
Message-ID: <200706231928.22862.info@gnebu.es> (raw)
In-Reply-To: <EC86BD0E-7829-4DBF-864A-795804235C5C@mac.com>

El Saturday 23 June 2007 18:35:18 Kyle Moffett escribió:
> If you want the kernel to
> treat one job or the other as more important then you must *TELL* it
> that, end of story.

Yes, that makes sense now that it's been explained to me conveniently. As long 
as a normal user is not left alone with such task (as it won't happen), I'm 
more than happy with the solution.

> > Yes, I see your point. In a scenario of dropping frames it seems
> > that CFS does a better job. It's just that an ideal scheduler
> > shouldn't drop frames in this case (it should give 70% to the video
> > even without nicing the encoder).
>
> It can't do that.  The with-CFS kernel just sees 2 CPU-heavy
> processes and guesses that it should give them equal CPU.  "stock"
> kernels have an algorithm designed to promote some tasks for
> "interactivity", but in practice it also tended to cause other
> processes to be denied CPU for arbitrarily long periods of time,
> hence why CFS is an improvement.  Under the old scheduler even if you
> had 2 DVD player processes each chewing 45% CPU, you could still have
> dropped frames because for a second or two one would be more
> "interactive" than the other, and vice versa.  Under CFS/SD, they are
> both classified equally and so get equal CPU allocation *AND* latency.

This adds even more sense to all the explanations I've heard up to now. 
Thanks :)

> I don't see any reason someone couldn't write a simple little GUI
> program to enumerate the user-owned X processes (somewhat like the
> Windows Task-Manager but less complicated) and allow them to change
> priorities.  Alternatively your desktop environment could set up a
> little privileged wrapper which appropriately executes the HD video
> player.  One of the primary rules of kernel development is that you
> cannot put policy in the kernel, and a statement of the form
> "PROCESS1 is more important than PROCESS2" is pure policy and must be
> done from userspace.  We even give appropriate enforcement mechanisms
> to userspace to take such action (nice levels).

Yes, an app to change priorities would be very nice, though I'd be happy with 
just sensible defaults. Probably once CFS or SD go mainline more application 
developers will make their apps run at the appropriate nice level (or else 
distributions will provide this when packaging the apps), so end users won't 
have any problems.

> Cheers,
> Kyle Moffett

Thank you,
Alberto.


  reply	other threads:[~2007-06-23 17:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-22 22:07 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 [this message]
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
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=200706231928.22862.info@gnebu.es \
    --to=info@gnebu.es \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mrmacman_g4@mac.com \
    /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

all inboxes | Powered by JetHome®