Messages in this thread | | | Date | Sun, 18 Jun 2006 16:11:18 +1000 | From | Nick Piggin <> | Subject | Re: [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/
| |