All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Williams <pwil3058@bigpond.net.au>
To: Kirill Korotaev <dev@openvz.org>
Cc: balbir@in.ibm.com, Mike Galbraith <efault@gmx.de>,
	Con Kolivas <kernel@kolivas.org>,
	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: Thu, 01 Jun 2006 09:39:32 +1000	[thread overview]
Message-ID: <447E2934.5090907@bigpond.net.au> (raw)
In-Reply-To: <447D975B.3070700@openvz.org>

Kirill Korotaev wrote:
>>> I understand that, I was talking about fairness between capped tasks
>>> and what might be considered fair or intutive between capped tasks and
>>> regular tasks. Of course, the last point is debatable ;)
>>
>>
>> Well, the primary fairness mechanism in the scheduler is the time 
>> slice allocation and the capping code doesn't fiddle with those so 
>> there should be a reasonable degree of fairness (taking into account 
>> "nice") between capped tasks.  To improve that would require 
>> allocating several new priority slots for use by tasks exceeding their 
>> caps and fiddling with those.  I don't think that it's worth the bother.

I think more needs to be said about the fairness issue.

1. If a task is getting its cap or more then it's getting its fair share 
as specified by that cap.  Yes?

2. If a task is getting less CPU usage then its cap then it will be 
being scheduled just as if it had no cap and will be getting its fair 
share just as much as any task is.

So there is no fairness problem.

> I suppose it should be handled still. a subjective feeling :)
> 
> BTW, do you have any test results for your patch?
> It would be interesting to see how precise these limitations are and 
> whether or not we should bother for the above...

I tend to test by observing the results of setting caps on running tasks 
and this doesn't generate something that can be e-mailed.

Observations indicate that hard caps are enforced to less than 1% and 
ditto for soft caps except for small soft caps where the fact (stated in 
the patches) that enforcement is not fully strict in order to prevent 
priority inversion or starvation means that the cap is generally 
exceeded.  I'm currently making modifications (based on suggestions by 
Con Kolivas) that implement an alternative method for avoiding priority 
inversion and starvation and allow the enforcement to be more strict.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce

  reply	other threads:[~2006-05-31 23:39 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
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 [this message]
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=447E2934.5090907@bigpond.net.au \
    --to=pwil3058@bigpond.net.au \
    --cc=balbir@in.ibm.com \
    --cc=dev@openvz.org \
    --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.