All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <piggin@cyberone.com.au>
To: "Martin J. Bligh" <mbligh@aracnet.com>
Cc: Mike Fedyk <mfedyk@matchmail.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Nick's scheduler policy v12
Date: Sat, 06 Sep 2003 11:18:35 +1000	[thread overview]
Message-ID: <3F5935EB.4000005@cyberone.com.au> (raw)
In-Reply-To: <207340000.1062793164@flay>



Martin J. Bligh wrote:

>>On Fri, Sep 05, 2003 at 11:54:04AM -0700, Martin J. Bligh wrote:
>>
>>>>Backboost is gone so X really should be at -10 or even higher.
>>>>
>>>Wasn't that causing half the problems originally? Boosting X seemed
>>>to starve xmms et al. Or do the interactivity changes fix xmms
>>>somehow, but not X itself? Explicitly fiddling with task's priorities
>>>seems flawed to me.
>>>
>>Wasn't it the larger timeslices with lower nice values in stock and Con's
>>patches that made X with nice -10 a bad idea?
>>
>
>Debian renices X by default to -10 ... I fixed all my desktop interactivity
>problems around 2.5.63 timeframe by just turning that off. That was way 
>before Con's patches.
>

Yep, as Mike mentioned, renicing X causes it to get bigger
timeslices with the stock scheduler. If you had 2 nice -20 processes,
they would each get a timeslice of 200ms, so you're harming their
latency.

>
>There may be some more details around this, and I'd love to hear them,
>but I fundmantally believe that explitit fiddling with particular
>processes because we believe they're somehow magic is wrong (and so
>does Linus, from previous discussions).
>

Well it would be nice if someone could find out how to do it, but I
think that if we want X to be able to get 80% CPU when 2 other CPU hogs
are running, you have to renice it.



  parent reply	other threads:[~2003-09-06  1:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-05 17:57 [PATCH] Nick's scheduler policy v12 Nick Piggin
2003-09-05 18:54 ` Martin J. Bligh
2003-09-05 20:22   ` Mike Fedyk
2003-09-05 20:19     ` Martin J. Bligh
2003-09-05 20:39       ` Mike Fedyk
2003-09-05 21:08         ` Robert Love
2003-09-06  1:31           ` Nick Piggin
2003-09-06  1:18       ` Nick Piggin [this message]
2003-09-06  3:36         ` Martin J. Bligh
2003-09-06  6:20           ` Jörn Engel
2003-09-06  6:38           ` Nick Piggin
2003-09-06  6:55             ` Nick Piggin
2003-09-06 15:13             ` Martin J. Bligh
2003-09-06 11:47               ` Ed Sweetman
2003-09-07  2:34                 ` Martin J. Bligh
2003-09-07  3:27                   ` Valdis.Kletnieks
2003-09-07  4:42                   ` Nick Piggin
2003-09-07  4:37               ` Nick Piggin
2003-09-06  7:49           ` Martin Schlemmer

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=3F5935EB.4000005@cyberone.com.au \
    --to=piggin@cyberone.com.au \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=mfedyk@matchmail.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 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.