From: Pavel Emelyanov <xemul@openvz.org>
To: Dhaval Giani <dhaval@linux.vnet.ibm.com>
Cc: Herbert Poetzl <herbert@13thfloor.at>,
vatsa@in.ibm.com, Bharata B Rao <bharata@linux.vnet.ibm.com>,
Balbir Singh <balbir@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org,
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 16:45:15 +0400 [thread overview]
Message-ID: <4AD4765B.3010907@openvz.org> (raw)
In-Reply-To: <20091013123047.GC26069@linux.vnet.ibm.com>
Dhaval Giani wrote:
> On Tue, Oct 13, 2009 at 04:19:41PM +0400, Pavel Emelyanov wrote:
>>> as I already stated, it seems perfectly fine for me
>> You're not the only one interested in it, sorry. Besides, I
>> got your point in "I'm find with it". Now get mine which is
>> about "I am not".
>>
>>> 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 :)
>> No I don't.
>> Is 1s/0.5s worse or better than 2s/1s?
>> How should I make a choice?
>
> I would say it depends on your requirement. How fast do you want to
> respond back to the user? Wiht lower bandwidth, you would want to have
> shorter periods so that the user would not get the impression that he
> has to "wait" to get CPU time. But having a very short period is not a
> good thing, since there are other considerations (such as the overhead of
> hard limits).
That's it - long period is bad for one reason, short period is bad for
some other one and neither of them is clearly described unlike the
limit itself.
In other words there are two numbers we're essentially playing with:
* the limit (int percents, Hz, whatever)
* and this abstract "badness"
Can't we give the user one of them for "must be configured" usage, put
the other one in some "good for most users" position and let the user
move it later on demand?
Yet again - weights in CFQ CPU-sched, ionoce in CFQ-iosched, bandwidth
in tc (traffic shaping), etc. are all clean for end-user. Plus there are
other fine tunes, that user should not configure by default, but which
change the default behavior. I propose to create simple and clean
interface for limits as well. If you think that virtual cpu power is
not good, ok. Let's ask user for a percentage and give him yet another
option to control this "badness" or "responsiveness".
> thanks,
next prev parent reply other threads:[~2009-10-13 12:46 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 [this message]
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=4AD4765B.3010907@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox