From: Pavel Emelyanov <xemul@openvz.org>
To: balbir@linux.vnet.ibm.com
Cc: bharata@linux.vnet.ibm.com, linux-kernel@vger.kernel.org,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>,
Gautham R Shenoy <ego@in.ibm.com>,
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Herbert Poetzl <herbert@13thfloor.at>,
Avi Kivity <avi@redhat.com>, Chris Friesen <cfriesen@nortel.com>,
Paul Menage <menage@google.com>,
Mike Waychison <mikew@google.com>
Subject: Re: [RFC v2 PATCH 0/8] CFS Hard limits - v2
Date: Wed, 30 Sep 2009 19:10:27 +0400 [thread overview]
Message-ID: <4AC374E3.9000308@openvz.org> (raw)
In-Reply-To: <20090930143820.GG3071@balbir.in.ibm.com>
Balbir Singh wrote:
> * Pavel Emelyanov <xemul@openvz.org> [2009-09-30 17:36:29]:
>
>> Bharata B Rao wrote:
>>> Hi,
>>>
>>> Here is the v2 post of hard limits feature for CFS group scheduler. This
>>> RFC post mainly adds runtime borrowing feature and has a new locking scheme
>>> to protect CFS runtime related fields.
>>>
>>> It would be nice to have some comments on this set!
>> I have a question I'd like to ask before diving into the code.
>> Consider I'm a user, that has a 4CPUs box 2GHz each and I'd like
>> to create a container with 2CPUs 1GHz each. Can I achieve this
>> after your patches?
>
> I don't think the GHz makes any sense, consider CPUs with frequency
> scaling. If I can scale from 1.6GHz to say 2.6GHz or 2GHz to 4GHz,
> what does it mean for hard limit control? Hard limits define control
> over existing bandwidth, anything else would be superficial and hard
> hard to get right for both developers and users.
Two numbers for configuring limits make even less sense OTOH ;)
By assigning 2GHz for 4GHz CPU I obviously want half of its power ;)
Please, see my reply to vatsa@ in this thread.
next prev parent reply other threads:[~2009-09-30 15:10 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-30 12:49 [RFC v2 PATCH 0/8] CFS Hard limits - v2 Bharata B Rao
2009-09-30 12:50 ` [RFC v2 PATCH 1/8] sched: Rename sched_rt_period_mask() and use it in CFS also Bharata B Rao
2009-09-30 12:51 ` [RFC v2 PATCH 2/8] sched: Maintain aggregated tasks count in cfs_rq at each hierarchy level Bharata B Rao
2009-10-13 14:27 ` Peter Zijlstra
2009-10-14 3:42 ` Bharata B Rao
2009-09-30 12:52 ` [RFC v2 PATCH 3/8] sched: Bandwidth initialization for fair task groups Bharata B Rao
2009-10-13 14:27 ` Peter Zijlstra
2009-10-14 3:49 ` Bharata B Rao
2009-09-30 12:52 ` [RFC v2 PATCH 4/8] sched: Enforce hard limits by throttling Bharata B Rao
2009-10-13 14:27 ` Peter Zijlstra
2009-10-14 3:41 ` Bharata B Rao
2009-10-14 9:17 ` Peter Zijlstra
2009-10-14 11:50 ` Bharata B Rao
2009-10-14 13:18 ` Herbert Poetzl
2009-10-15 3:30 ` Bharata B Rao
2009-09-30 12:53 ` [RFC v2 PATCH 5/8] sched: Unthrottle the throttled tasks Bharata B Rao
2009-09-30 12:54 ` [RFC v2 PATCH 6/8] sched: Add throttle time statistics to /proc/sched_debug Bharata B Rao
2009-09-30 12:55 ` [RFC v2 PATCH 7/8] sched: Rebalance cfs runtimes Bharata B Rao
2009-09-30 12:55 ` [RFC v2 PATCH 8/8] sched: Hard limits documentation Bharata B Rao
2009-09-30 13:36 ` [RFC v2 PATCH 0/8] CFS Hard limits - v2 Pavel Emelyanov
2009-09-30 14:25 ` Bharata B Rao
2009-09-30 14:39 ` Srivatsa Vaddagiri
2009-09-30 15:09 ` Pavel Emelyanov
2009-10-13 11:39 ` Pavel Emelyanov
2009-10-13 12:03 ` Herbert Poetzl
2009-10-13 12:19 ` Pavel Emelyanov
2009-10-13 12:30 ` Dhaval Giani
2009-10-13 12:45 ` Pavel Emelyanov
2009-10-13 12:56 ` Dhaval Giani
2009-10-13 12:57 ` Bharata B Rao
2009-10-13 13:01 ` Pavel Emelyanov
2009-10-13 14:56 ` Valdis.Kletnieks
2009-10-13 22:02 ` Herbert Poetzl
2009-10-13 14:49 ` Valdis.Kletnieks
2009-09-30 14:38 ` Balbir Singh
2009-09-30 15:10 ` Pavel Emelyanov [this message]
2009-09-30 15:30 ` Balbir Singh
2009-09-30 22:30 ` Herbert Poetzl
2009-10-01 5:12 ` Bharata B Rao
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=4AC374E3.9000308@openvz.org \
--to=xemul@openvz.org \
--cc=a.p.zijlstra@chello.nl \
--cc=avi@redhat.com \
--cc=balbir@linux.vnet.ibm.com \
--cc=bharata@linux.vnet.ibm.com \
--cc=cfriesen@nortel.com \
--cc=dhaval@linux.vnet.ibm.com \
--cc=ego@in.ibm.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=mikew@google.com \
--cc=mingo@elte.hu \
--cc=svaidy@linux.vnet.ibm.com \
--cc=vatsa@in.ibm.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.