Re: [RFC] CPU controllers?

From: Nick Piggin
Date: Sun Jun 18 2006 - 02:11:53 EST


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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/