From: Peter Williams <pwil3058@bigpond.net.au>
To: Con Kolivas <kernel@kolivas.org>
Cc: Mike Galbraith <efault@gmx.de>,
Linux Kernel <linux-kernel@vger.kernel.org>,
Kingsley Cheung <kingsley@aurema.com>,
Ingo Molnar <mingo@elte.hu>,
Rene Herman <rene.herman@keyaccess.nl>
Subject: Re: [RFC 2/5] sched: Add CPU rate soft caps
Date: Fri, 26 May 2006 23:55:36 +1000 [thread overview]
Message-ID: <447708D8.6040000@bigpond.net.au> (raw)
In-Reply-To: <200605262048.53131.kernel@kolivas.org>
Con Kolivas wrote:
> On Friday 26 May 2006 14:20, Peter Williams wrote:
>> This patch implements (soft) CPU rate caps per task as a proportion of a
>> single CPU's capacity expressed in parts per thousand. The CPU usage
>> of capped tasks is determined by using Kalman filters to calculate the
>> (recent) average lengths of the task's scheduling cycle and the time
>> spent on the CPU each cycle and taking the ratio of the latter to the
>> former. To minimize overhead associated with uncapped tasks these
>> statistics are not kept for them.
>>
>> Notes:
>>
>> 1. To minimize the overhead incurred when testing to skip caps processing
>> for uncapped tasks a new flag PF_HAS_CAP has been added to flags.
>
> [ot]I'm sorry to see an Australian adopt American spelling [/ot]
I think you'll find the Oxford English Dictionary (which was the
reference when I went to school in the middle of last century) uses the
z and offers the s version as an option.
>
>> 3. Enforcement of caps is not as strict as it could be in order to
>> reduce the possibility of a task being starved of CPU while holding
>> an important system resource with resultant overall performance
>> degradation. In effect, all runnable capped tasks will get some amount
>> of CPU access every active/expired swap cycle. This will be most
>> apparent for small or zero soft caps.
>
> The array swap happens very frequently if there are nothing but heavily cpu
> bound tasks, which is not an infrequent workload. I doubt the zero caps are
> very effective in that environment.
Yes and it depends on HZ as well (i.e. it works better when HZis zero).
With HZ=250 and a zero capped hard spinning task competing with
another hard spinning task on a single CPU system it struggles to keep
it below below 4%. I've tested hard caps down to 0.5% in the same test
and it copes. So a long term solution such as something similar to the
rt_mutex priority inheritance is needed so that stricter soft capping
can be enforced. I don't think that it would be hard to be more strict
as it would just involve some checking when determining idx in schedule().
BTW in my SPA schedulers this can be controlled by varying the promotion
rate.
Peter
--
Peter Williams pwil3058@bigpond.net.au
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
next prev parent reply other threads:[~2006-05-26 13:55 UTC|newest]
Thread overview: 95+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-26 4:20 [RFC 0/5] sched: Add CPU rate caps Peter Williams
2006-05-26 4:20 ` [RFC 1/5] sched: Fix priority inheritence before CPU rate soft caps Peter Williams
2006-05-26 4:20 ` [RFC 2/5] sched: Add " Peter Williams
2006-05-26 10:48 ` Con Kolivas
2006-05-26 11:15 ` Mike Galbraith
2006-05-26 11:17 ` Con Kolivas
2006-05-26 11:30 ` Mike Galbraith
2006-05-26 13:55 ` Peter Williams [this message]
2006-05-27 6:31 ` Balbir Singh
2006-05-27 7:03 ` Peter Williams
2006-05-28 0:11 ` Peter Williams
2006-05-28 7:38 ` Balbir Singh
2006-05-28 13:35 ` Peter Williams
2006-05-28 14:42 ` Balbir Singh
2006-05-28 23:27 ` Peter Williams
2006-05-31 13:17 ` Kirill Korotaev
2006-05-31 23:39 ` Peter Williams
2006-06-01 8:09 ` Kirill Korotaev
2006-06-01 23:38 ` Peter Williams
2006-06-02 1:35 ` Peter Williams
2006-05-26 4:20 ` [RFC 3/5] sched: Add CPU rate hard caps Peter Williams
2006-05-26 6:58 ` Kari Hurtta
2006-05-27 1:00 ` Peter Williams
2006-05-26 11:00 ` Con Kolivas
2006-05-26 13:59 ` Peter Williams
2006-05-26 14:12 ` Con Kolivas
2006-05-26 14:23 ` Mike Galbraith
2006-05-27 0:16 ` Peter Williams
2006-05-27 9:28 ` Mike Galbraith
2006-05-28 2:09 ` Peter Williams
2006-05-27 6:48 ` Balbir Singh
2006-05-27 8:44 ` Peter Williams
2006-05-31 13:10 ` Kirill Korotaev
2006-05-31 15:59 ` Balbir Singh
2006-05-31 18:09 ` Mike Galbraith
2006-06-01 7:41 ` Kirill Korotaev
2006-06-01 8:34 ` Balbir Singh
2006-06-01 18:43 ` [ckrm-tech] " Chandra Seetharaman
2006-06-01 23:26 ` Peter Williams
2006-06-02 2:02 ` Chandra Seetharaman
2006-06-02 3:21 ` Peter Williams
2006-06-02 8:32 ` Balbir Singh
2006-06-02 13:30 ` Peter Williams
2006-06-02 18:58 ` Balbir Singh
2006-06-02 23:49 ` Peter Williams
2006-06-03 4:59 ` Balbir Singh
2006-06-02 19:06 ` Chandra Seetharaman
2006-06-03 0:04 ` Peter Williams
2006-06-02 0:36 ` Con Kolivas
2006-06-02 2:03 ` [ckrm-tech] " Chandra Seetharaman
2006-06-02 5:55 ` [ckrm-tech] [RFC 3/5] " Peter Williams
2006-06-02 7:47 ` Kirill Korotaev
2006-06-02 13:34 ` Peter Williams
2006-06-05 22:11 ` Sam Vilain
2006-06-06 8:24 ` Kirill Korotaev
2006-06-06 9:13 ` Con Kolivas
2006-06-06 9:28 ` Kirill Korotaev
2006-06-02 8:46 ` Mike Galbraith
2006-06-02 13:18 ` Peter Williams
2006-06-02 14:47 ` Mike Galbraith
2006-06-03 0:08 ` Peter Williams
2006-06-03 6:02 ` Mike Galbraith
2006-06-03 11:03 ` Peter Williams
2006-06-06 11:26 ` Srivatsa Vaddagiri
2006-06-02 7:34 ` Kirill Korotaev
2006-06-02 21:23 ` Shailabh Nagar
2006-06-01 23:47 ` Sam Vilain
2006-06-01 23:43 ` Peter Williams
2006-05-31 23:28 ` Peter Williams
2006-06-01 7:44 ` Kirill Korotaev
2006-06-01 23:21 ` Peter Williams
2006-05-26 4:21 ` [RFC 4/5] sched: Add procfs interface for CPU rate soft caps Peter Williams
2006-05-26 4:21 ` [RFC 5/5] sched: Add procfs interface for CPU rate hard caps Peter Williams
2006-05-26 8:04 ` [RFC 0/5] sched: Add CPU rate caps Mike Galbraith
2006-05-26 16:11 ` Björn Steinbrink
2006-05-28 22:46 ` Sam Vilain
2006-05-28 23:30 ` Peter Williams
2006-05-29 3:09 ` Sam Vilain
2006-05-29 3:41 ` Peter Williams
2006-05-29 21:16 ` Sam Vilain
2006-05-29 23:12 ` Peter Williams
2006-05-30 2:07 ` Sam Vilain
2006-05-30 2:45 ` Peter Williams
2006-05-30 22:05 ` Sam Vilain
2006-05-30 23:22 ` Peter Williams
2006-05-30 23:25 ` Peter Williams
2006-06-05 23:56 ` Peter Williams
2006-05-27 0:16 ` Peter Williams
2006-05-26 10:41 ` Con Kolivas
2006-05-27 1:28 ` Peter Williams
2006-05-27 1:42 ` Con Kolivas
2006-05-26 11:09 ` Con Kolivas
2006-05-26 14:00 ` Peter Williams
2006-05-26 11:29 ` Balbir Singh
2006-05-27 1:40 ` 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=447708D8.6040000@bigpond.net.au \
--to=pwil3058@bigpond.net.au \
--cc=efault@gmx.de \
--cc=kernel@kolivas.org \
--cc=kingsley@aurema.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rene.herman@keyaccess.nl \
/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.