mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Herbert Poetzl <herbert@13thfloor.at>
To: Pavel Emelyanov <xemul@openvz.org>
Cc: vatsa@in.ibm.com, Bharata B Rao <bharata@linux.vnet.ibm.com>,
	Balbir Singh <balbir@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>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	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: Tue, 13 Oct 2009 14:03:54 +0200	[thread overview]
Message-ID: <20091013120354.GF24787@MAIL.13thfloor.at> (raw)
In-Reply-To: <4AD466E5.4010206@openvz.org>

On Tue, Oct 13, 2009 at 03:39:17PM +0400, Pavel Emelyanov wrote:
> > IMO Pavel's requirement can be met with a hard limit of 25%
> > 
> > 	2 CPU of 1GHz = (1/2 x 4) (1/2 x 2) GHz CPUs
> > 		      = 1/4 x 4 2GHz CPU
> > 		      = 25% of (4 2GHz CPU)
> > 
> > IOW by hard-limiting a container thread to run just 0.5sec every
> > sec on a 2GHz cpu, it is effectively making progress at the rate of
> > 1GHz?

> So, any suggestions on this? I'm not against the patches themselves.
> I'm just trying to tell, that setting a cpulimit with 2 numbers is
> not a good way to go (at least a clean explanation of how to calculate
> them should go with the patches).

as I already stated, it seems perfectly fine for me (to have
two values, period and runtime), IMHO it is quite natural to 
understand and it allows (to some degree) to control the
scheduling behaviour by controlling the multiplicator (i.e.
use 1s/0.5s vs 100ms/50ms) ...

we already incorporated the patch (for testing) in our
current release, and it seems to work fine and do what we
need/want (see http://linux-vserver.org/util-vserver:Cgroups)

> I propose to first collect what *can* be done. I see the following
> possibilities:

> 1) two times (as it is now) - I believe this is inconvenient.
> 2) the amount in percents (like 50%) - this is how it works in
>    OpenVZ and customers are quite happy with it. It's better than
>    two numbers, since you need to specify only one clean number.

can be trivially mapped to the two values, by chosing a
fixed multiplicative base (let's say '1s' to simplify :) 

  with 50%, you get 1s/0.5s
  with 20%, you get 1s/0.2s
  with  5%, you get 1s/0.05s

well, you get the idea :)

> 3) virtual cpu power in M/GHz - I don't agree with Balbir that
>    this is difficult for administrator. This is better than two
>    numbers and better that the percentage, since the amount of
>    cpu time got by a container will not change after migrating to
>    a more powerful CPU.

I think this is completely artificial, and adds a lot
of silly cornercases, like e.g. cpu speed changes (think
SpeedStep and friends) and doesn't help the administration
in any way ... nevertheless, it should also be trivial to
map to the two values if you do the following:

  Host CPU = 4.5GHz
  Desired Guest CPU = 2.0Ghz

  2.0/4.5 = 0.44' -> 44% -> 1s/0.44s

> Thoughts?

so once again, 'we' (Linux-VServer) are perfectly happy
with the current status, the only difference to what we
used to have is that we calculated the period and runtime
in jiffies not micro seconds, and called them interval
and rate (which is as simple to map as the percentage
OpenVZ uses)

best,
Herbert

> > - vatsa
> > 

  reply	other threads:[~2009-10-13 12:04 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-30 12:49 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 [this message]
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
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=20091013120354.GF24787@MAIL.13thfloor.at \
    --to=herbert@13thfloor.at \
    --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=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 \
    --cc=xemul@openvz.org \
    /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

all inboxes | Powered by JetHome®