From: Peter Williams <pwil3058@bigpond.net.au>
To: Al Boldi <a1426z@gawab.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Announce] [patch] Modular Scheduler Core and Completely Fair
Date: Tue, 17 Apr 2007 10:42:29 +1000 [thread overview]
Message-ID: <462417F5.2060507@bigpond.net.au> (raw)
In-Reply-To: <200704161738.47956.a1426z@gawab.com>
Al Boldi wrote:
> Peter Williams wrote:
>> Al Boldi wrote:
>>> Reducing the prio-level granularity may also be helpful;
>> Because of some of the bit operations code makes it a bad idea to have
>> more than 160 priority levels, you're more or less limited to 60
>> priority levels for SCHED_OTHER tasks (as 100 are used for real time)
>> and you need 40 of these to pay some attention to niceness leaving you
>> about 20 priority levels to use for fiddling. Is that enough?
>>
>> With spa_ebs (now that CPU rate caps have been removed), you have all 60
>> priorities available for fiddling with as niceness is taken care of when
>> calculating each task's entitlement.
>
> Ok, increasing the number of prio-levels is one thing, but I was more
> thinking of reducing the effective difference between each prio-level. For
> example, this would allow max_tpt_bonus=18, while the effective range would
> be 3, thus reducing granularity. Would this be easily introduceable?
OK. Now (I think) I see what you mean. I think that you could achieve
this effect by shortening the promotion interval which I think is still
one of the tunables. This effectively controls the strength of priority
levels -- short promotion intervals weaken and long promotion intervals
strengthen the effect of different priority levels.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
next prev parent reply other threads:[~2007-04-17 0:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-15 6:31 [Announce] [patch] Modular Scheduler Core and Completely Fair Al Boldi
2007-04-16 8:53 ` Al Boldi
2007-04-16 10:18 ` Peter Williams
2007-04-16 10:42 ` Al Boldi
2007-04-16 13:05 ` Peter Williams
2007-04-16 14:38 ` Al Boldi
2007-04-17 0:42 ` Peter Williams [this message]
2007-04-16 14:38 ` Al Boldi
2007-04-17 16:29 ` Al Boldi
2007-04-17 21:45 ` William Lee Irwin III
2007-04-18 4:53 ` Al Boldi
[not found] <E1HOuCl-0000K8-3c@mx1.bon.at>
2007-04-19 6:11 ` Ph. Marek
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=462417F5.2060507@bigpond.net.au \
--to=pwil3058@bigpond.net.au \
--cc=a1426z@gawab.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox