From: Kir Kolyshkin <kir@openvz.org>
To: devel@openvz.org
Cc: vatsa@in.ibm.com, dev@openvz.org, sekharan@us.ibm.com,
ckrm-tech@lists.sourceforge.net, balbir@in.ibm.com,
linux-kernel@vger.kernel.org, pj@sgi.com, matthltc@us.ibm.com,
dipankar@in.ibm.com, rohitseth@google.com,
Paul Menage <menage@google.com>,
Chris Friesen <cfriesen@nortel.com>
Subject: Re: [Devel] Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices
Date: Thu, 02 Nov 2006 02:01:56 +0300 [thread overview]
Message-ID: <45492764.6060700@openvz.org> (raw)
In-Reply-To: <45490F0D.7000804@nortel.com>
Chris Friesen wrote:
> Srivatsa Vaddagiri wrote:
>
>>>> - Support limit (soft and/or hard depending on the resource
>>>> type) in controllers. Guarantee feature could be indirectly
>>>> met thr limits.
>
> I just thought I'd weigh in on this. As far as our usage pattern is
> concerned, guarantees cannot be met via limits.
>
> I want to give "x" cpu to container X, "y" cpu to container Y, and "z"
> cpu to container Z.
>
> If these are percentages, x+y+z must be less than 100.
>
> However, if Y does not use its share of the cpu, I would like the
> leftover cpu time to be made available to X and Z, in a ratio based on
> their allocated weights.
>
> With limits, I don't see how I can get the ability for containers to
> make opportunistic use of cpu that becomes available.
This is basically how "cpuunits" in OpenVZ works. It is not limiting a
container in any way, just assigns some relative "units" to it, with sum
of all units across all containers equal to 100% CPU. Thus, if we have
cpuunits 10, 20, and 30 assigned to containers X, Y, and Z, and run some
CPU-intensive tasks in all the containers, X will be given
10/(10+20+30), or 20% of CPU time, Y -- 20/50, i.e. 40%, while Z gets
60%. Now, if Z is not using CPU, X will be given 33% and Y -- 66%. The
scheduler used is based on a per-VE runqueues, is quite fair, and works
fine and fair for, say, uneven case of 3 containers on a 4 CPU box.
OpenVZ also has a "cpulimit" resource, which is, naturally, a hard limit
of CPU usage for a VE. Still, given the fact that cpunits works just
fine, cpulimit is rarely needed -- makes sense only in special scenarios
where you want to see how app is run on a slow box, or in case of some
proprietary software licensed per CPU MHZ, or smth like that.
Looks like this is what you need, right?
> I can see that with things like memory this could become tricky (How
> do you free up memory that was allocated to X when Y decides that it
> really wants it after all?) but for CPU I think it's a valid scenario.
Yes, CPU controller is quite different of other resource controllers.
Kir.
next prev parent reply other threads:[~2006-11-01 23:04 UTC|newest]
Thread overview: 135+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-30 10:33 [RFC] Resource Management - Infrastructure choices Srivatsa Vaddagiri
2006-10-30 10:34 ` RFC: Memory Controller Balbir Singh
2006-10-30 11:04 ` Paul Menage
2006-10-30 13:27 ` [ckrm-tech] " Balbir Singh
2006-10-30 18:14 ` Paul Menage
2006-10-31 17:07 ` Balbir Singh
2006-10-31 17:22 ` Paul Menage
2006-10-31 18:16 ` Badari Pulavarty
2006-11-01 7:05 ` Balbir Singh
2006-11-01 7:07 ` Paul Menage
2006-11-01 7:44 ` Balbir Singh
2006-11-01 12:23 ` Paul Jackson
2006-11-02 0:09 ` Paul Menage
2006-11-02 0:39 ` Paul Jackson
2006-10-30 15:58 ` Pavel Emelianov
2006-10-30 17:39 ` Balbir Singh
2006-10-30 18:07 ` Balbir Singh
2006-10-31 8:57 ` Pavel Emelianov
2006-10-31 9:19 ` Balbir Singh
2006-10-31 9:25 ` Pavel Emelianov
2006-10-31 10:10 ` Balbir Singh
2006-10-31 10:19 ` Pavel Emelianov
2006-10-31 9:42 ` Andrew Morton
2006-10-31 10:36 ` Balbir Singh
2006-10-31 8:48 ` Pavel Emelianov
2006-10-31 10:54 ` Balbir Singh
2006-10-31 11:15 ` Pavel Emelianov
2006-10-31 12:39 ` Balbir Singh
2006-10-31 14:19 ` Pavel Emelianov
2006-10-31 16:54 ` Paul Menage
2006-11-01 6:00 ` David Rientjes
2006-11-01 8:05 ` Pavel Emelianov
2006-11-01 8:35 ` David Rientjes
2006-10-31 17:04 ` Dave Hansen
2006-11-01 7:57 ` Pavel Emelianov
2006-10-30 18:20 ` Paul Menage
2006-10-30 21:38 ` Paul Jackson
2006-10-30 10:43 ` [RFC] Resource Management - Infrastructure choices Paul Jackson
2006-10-30 14:19 ` [ckrm-tech] " Pavel Emelianov
2006-10-30 14:29 ` Paul Jackson
2006-10-30 17:09 ` Srivatsa Vaddagiri
2006-10-30 17:16 ` Dave McCracken
2006-10-30 18:07 ` Paul Menage
2006-10-30 20:41 ` Paul Jackson
2006-10-30 10:51 ` Paul Menage
2006-10-30 11:06 ` [ckrm-tech] " Paul Jackson
2006-10-30 12:07 ` Paul Menage
2006-10-30 12:28 ` Paul Jackson
2006-10-30 11:15 ` Paul Jackson
2006-10-30 12:04 ` Paul Menage
2006-10-30 12:27 ` Paul Jackson
2006-10-30 17:53 ` Paul Menage
2006-10-30 20:36 ` Paul Jackson
2006-10-30 20:47 ` Paul Menage
2006-10-30 20:56 ` Paul Jackson
2006-10-30 21:03 ` Paul Menage
2006-10-31 11:53 ` Srivatsa Vaddagiri
2006-10-31 13:31 ` Srivatsa Vaddagiri
2006-10-31 16:46 ` Paul Menage
2006-11-01 17:25 ` Srivatsa Vaddagiri
2006-11-01 23:37 ` Paul Menage
2006-11-06 12:49 ` Srivatsa Vaddagiri
2006-11-06 20:23 ` Paul Menage
2006-11-07 13:20 ` Srivatsa Vaddagiri
2006-11-07 18:41 ` Paul Jackson
2006-11-07 19:07 ` Paul Menage
2006-11-07 19:11 ` Paul Jackson
2006-11-07 19:24 ` Paul Menage
2006-11-07 19:58 ` Paul Jackson
2006-11-07 20:00 ` Paul Menage
2006-11-07 20:02 ` Paul Jackson
2006-11-08 2:47 ` Matt Helsley
2006-11-07 20:34 ` Paul Jackson
2006-11-07 20:41 ` Paul Menage
2006-11-07 21:50 ` Paul Jackson
2006-11-07 22:21 ` Paul Menage
2006-11-08 3:15 ` Paul Jackson
2006-11-08 4:15 ` Paul Menage
2006-11-08 4:16 ` Paul Jackson
2006-11-08 11:22 ` Paul Jackson
2006-11-08 5:12 ` Srivatsa Vaddagiri
2006-11-08 5:36 ` Paul Jackson
2006-11-09 5:39 ` Balbir Singh
2006-11-08 19:25 ` Chris Friesen
2006-11-09 3:54 ` Srivatsa Vaddagiri
2006-11-10 14:57 ` Srivatsa Vaddagiri
2006-11-01 4:39 ` David Rientjes
2006-11-01 9:50 ` Paul Jackson
2006-11-01 9:58 ` David Rientjes
2006-11-01 15:59 ` Srivatsa Vaddagiri
2006-11-01 16:31 ` Srivatsa Vaddagiri
2006-11-01 21:05 ` David Rientjes
2006-11-01 23:43 ` Paul Menage
2006-11-01 18:19 ` Srivatsa Vaddagiri
2006-11-01 17:33 ` Srivatsa Vaddagiri
2006-11-01 21:18 ` Chris Friesen
2006-11-01 23:01 ` Kir Kolyshkin [this message]
2006-11-02 0:31 ` [Devel] " Matt Helsley
2006-11-02 8:34 ` Kir Kolyshkin
2006-11-01 23:48 ` Paul Menage
2006-11-02 3:28 ` Chris Friesen
2006-11-02 7:40 ` Paul Menage
2006-10-30 14:08 ` Pavel Emelianov
2006-10-30 14:23 ` Paul Jackson
2006-10-30 14:38 ` Pavel Emelianov
2006-10-30 15:18 ` Paul Jackson
2006-10-30 15:26 ` Pavel Emelianov
2006-10-31 0:26 ` Matt Helsley
2006-10-31 8:34 ` Pavel Emelianov
2006-10-31 16:33 ` Chris Friesen
2006-10-30 18:01 ` Paul Menage
2006-10-31 8:31 ` Pavel Emelianov
2006-10-31 16:34 ` Paul Menage
2006-10-31 16:57 ` Srivatsa Vaddagiri
2006-11-01 7:58 ` Pavel Emelianov
2006-10-31 16:34 ` Srivatsa Vaddagiri
2006-11-01 8:01 ` Pavel Emelianov
2006-11-01 16:04 ` Matt Helsley
2006-11-01 17:51 ` Srivatsa Vaddagiri
2006-11-01 17:50 ` Srivatsa Vaddagiri
2006-11-02 8:42 ` Pavel Emelianov
2006-11-03 1:29 ` David Rientjes
2006-11-01 9:30 ` Pavel Emelianov
2006-11-01 9:53 ` David Rientjes
2006-11-01 22:23 ` Matt Helsley
2006-11-01 18:12 ` Srivatsa Vaddagiri
2006-11-01 22:19 ` Matt Helsley
2006-11-01 23:50 ` Paul Menage
2006-11-02 0:30 ` Matt Helsley
2006-11-02 5:33 ` Balbir Singh
2006-11-02 9:08 ` Pavel Emelianov
2006-11-02 11:26 ` Matt Helsley
2006-11-02 13:04 ` Pavel Emelianov
2006-11-03 1:29 ` David Rientjes
2006-11-02 8:52 ` Pavel Emelianov
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=45492764.6060700@openvz.org \
--to=kir@openvz.org \
--cc=balbir@in.ibm.com \
--cc=cfriesen@nortel.com \
--cc=ckrm-tech@lists.sourceforge.net \
--cc=dev@openvz.org \
--cc=devel@openvz.org \
--cc=dipankar@in.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=matthltc@us.ibm.com \
--cc=menage@google.com \
--cc=pj@sgi.com \
--cc=rohitseth@google.com \
--cc=sekharan@us.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox