public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sam Vilain <sam@vilain.net>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: vatsa@in.ibm.com, Kirill Korotaev <dev@openvz.org>,
	Mike Galbraith <efault@gmx.de>, Ingo Molnar <mingo@elte.hu>,
	Peter Williams <pwil3058@bigpond.net.au>,
	Andrew Morton <akpm@osdl.org>,
	sekharan@us.ibm.com, Balbir Singh <balbir@in.ibm.com>,
	linux-kernel@vger.kernel.org, maeda.naoaki@jp.fujitsu.com,
	kurosawa@valinux.co.jp
Subject: Re: [RFC] CPU controllers?
Date: Sun, 18 Jun 2006 17:53:42 +1200	[thread overview]
Message-ID: <4494EA66.8030305@vilain.net> (raw)
In-Reply-To: <4494DF50.2070509@yahoo.com.au>

Nick Piggin wrote:
>> I think a proportional-share scheduler (which is what a CPU controller
>> may provide) has non-container uses also. Do you think nice (or sched 
>> policy) is enough to, say, provide guaranteed CPU usage for 
>> applications or limit their CPU usage? Moreover it is more flexible 
>> if guarantee/limit can be specified for a group of tasks, rather than 
>> individual tasks even in
>> non-container scenarios (like limiting CPU usage of all web-server 
>> tasks togther or for limiting CPU usage of make -j command).
>>
>
> Oh, I'm sure there are lots of things we *could* do that we currently 
> can't.
>
> What I want to establish first is: what exact functionality is 
> required, why, and by whom.

You make it sound like users should feel sorry for wanting features 
already commonly available on other high performance unix kernels.

The answer is quite simple, people who are consolidating systems and 
working with fewer, larger systems, want to mark processes, groups of 
processes or entire containers into CPU scheduling classes, then either 
fair balance between them, limit them or reserve them a portion of the 
CPU - depending on the user and what their requirements are. What is 
unclear about that?

Yes, this does get somewhat simpler if you strap yourself into a 
complete virtualisation straightjacket, but the current thread is not 
about that approach - and the continual suggestions that we are all just 
being stupid and going about it the wrong way are locally off-topic.

Bear in mind that we have on the table at least one group of scheduling 
solutions (timeslice scaling based ones, such as the VServer one) which 
is virtually no overhead and could potentially provide the "jumpers" 
necessary for implementing more complex scheduling policies.

Sam.

> Only then can we sanely discuss the fitness of solutions and propose 
> alternatives, and decide whether to merge.


  reply	other threads:[~2006-06-18  5:54 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-15 13:46 [RFC] CPU controllers? Srivatsa Vaddagiri
2006-06-15 21:52 ` Sam Vilain
2006-06-15 23:30 ` Peter Williams
2006-06-16  0:42   ` Matt Helsley
2006-06-17  8:48 ` Nick Piggin
2006-06-17 15:55   ` Balbir Singh
2006-06-17 16:48   ` Srivatsa Vaddagiri
2006-06-18  5:06     ` Nick Piggin
2006-06-18  5:53       ` Sam Vilain [this message]
2006-06-18  6:11         ` Nick Piggin
2006-06-18  6:40           ` Sam Vilain
2006-06-18  7:17             ` Nick Piggin
2006-06-18  6:42           ` Andrew Morton
2006-06-18  7:28             ` Nick Piggin
2006-06-19 19:03               ` Resource Management Requirements (was "[RFC] CPU controllers?") Chandra Seetharaman
2006-06-20  5:40                 ` Srivatsa Vaddagiri
2006-06-18  7:36             ` [RFC] CPU controllers? Mike Galbraith
2006-06-18  7:49               ` Nick Piggin
2006-06-18  7:49               ` Nick Piggin
2006-06-18  9:09               ` Andrew Morton
2006-06-18  9:49                 ` Mike Galbraith
2006-06-19  6:28                   ` Mike Galbraith
2006-06-19  6:35                     ` Andrew Morton
2006-06-19  6:46                       ` Mike Galbraith
2006-06-19 18:21               ` Chris Friesen
2006-06-20  6:20                 ` Mike Galbraith
2006-06-18  7:18         ` Srivatsa Vaddagiri
2006-06-19  2:07           ` Sam Vilain
2006-06-19  7:04             ` MAEDA Naoaki
2006-06-19  8:19               ` Sam Vilain
2006-06-19  8:41                 ` MAEDA Naoaki
2006-06-19  8:53                   ` Sam Vilain
2006-06-19 21:44                     ` MAEDA Naoaki
2006-06-19 18:14   ` Chris Friesen
2006-06-19 19:11     ` Chandra Seetharaman
2006-06-19 20:28       ` Chris Friesen

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=4494EA66.8030305@vilain.net \
    --to=sam@vilain.net \
    --cc=akpm@osdl.org \
    --cc=balbir@in.ibm.com \
    --cc=dev@openvz.org \
    --cc=efault@gmx.de \
    --cc=kurosawa@valinux.co.jp \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maeda.naoaki@jp.fujitsu.com \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=pwil3058@bigpond.net.au \
    --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