From: Ingo Molnar <mingo@elte.hu>
To: Peter Williams <pwil3058@bigpond.net.au>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] cpu scheduler: unsquish dynamic priorities
Date: Wed, 21 Dec 2005 10:36:29 +0100 [thread overview]
Message-ID: <20051221093629.GA19867@elte.hu> (raw)
In-Reply-To: <43A78E33.7040307@bigpond.net.au>
* Peter Williams <pwil3058@bigpond.net.au> wrote:
> The problem:
>
> The current scheduler implementation maps 40 nice values and 10 bonus
> values into only 40 priority slots on the run queues. This results in
> the dynamic priorities of tasks at either end of the nice scale being
> squished up. E.g. all tasks with nice in the range -20 to -16 and the
> maximum of 10 bonus points will end up with a dynamic priority of
> MAX_RT_PRIO and all tasks with nice in the range 15 to 19 and no bonus
> points will end up with a dynamic priority of MAX_PRIO - 1.
>
> Although the fact that niceness is primarily implemented by time slice
> size means that this will have little or no adverse effect on the long
> term allocation of CPU resources due to niceness, it could adversely
> effect latency as it will interfere with preemption.
this property of the priority distribution was intentional from me, i
wanted to have an easy way to test 'no priority boosting downwards'
(nice +19) and 'no priority boosting upwards' (nice -20) conditions. But
i like your patch, because it simplifies effective_prio() a bit, and
with SCHED_BATCH we'll have the 'no boosting' property anyway. Could you
redo the patch against the current scheduler queue in -mm, so that we
can try it out in -mm?
Btw., another user-visible effect is that task_prio() will return the
new range, which will be visible in e.g. 'top'. I dont think it will be
confusing though.
Ingo
next prev parent reply other threads:[~2005-12-21 9:37 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-20 4:53 [PATCH] cpu scheduler: unsquish dynamic priorities Peter Williams
2005-12-21 5:21 ` Peter Williams
2005-12-21 9:36 ` Ingo Molnar [this message]
2005-12-22 0:41 ` Peter Williams
2006-01-06 5:22 ` Peter Williams
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=20051221093629.GA19867@elte.hu \
--to=mingo@elte.hu \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pwil3058@bigpond.net.au \
/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.