lkml.org 
[lkml]   [2006]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC] CPU controllers?
Sam Vilain wrote:
> 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.

If telling me what exact functionality they want is going to cause them
so much pain, I suppose they should feel sorry for themselves.

And I don't care about any other kernels, unix or not. I care about what
Linux users want.

>
> 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?
>

It is unclear whether we should have hard limits, or just nice like
priority levels. Whether virtualisation (+/- containers) could be a
good solution, etc.

If you want to *completely* isolate N groups of users, surely you
have to use virtualisation, unless you are willing to isolate memory
management, pagecache, slab caches, network and disk IO, etc.

> 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.

I'm sorry you cannot come up with a statement of the functionality you
require without badmouthing "complete" virtualisation or implying that
I'm saying you're stupid.

I think the containers people might also recognise that it may not be
the best solution to make containers the be all and end all of
consolidating systems, and virtualisation is a very relevant topic when
discussing pros and cons and alternate solutions.

But at this point I'm yet to be shown what the *problem* is. I'm not
trying to deny that one might exist.

>
> 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.

Again, I don't care about the solutions at this stage. I want to know
what the problem is. Please?

--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2006-06-18 08:13    [W:0.144 / U:0.316 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site