Messages in this thread | | | Date | Thu, 01 Jun 2006 14:04:28 +0530 | From | Balbir Singh <> | Subject | Re: [RFC 3/5] sched: Add CPU rate hard caps |
| |
Hi, Kirill,
Kirill Korotaev wrote: >> Do you have any documented requirements for container resource >> management? >> Is there a minimum list of features and nice to have features for >> containers >> as far as resource management is concerned? > > Sure! You can check OpenVZ project (http://openvz.org) for example of > required resource management. BTW, I must agree with other people here > who noticed that per-process resource management is really useless and > hard to use :(
I'll take a look at the references. I agree with you that it will be useful to have resource management for a group of tasks.
> > Briefly about required resource management: > 1) CPU: > - fairness (i.e. prioritization of containers). For this we use SFQ like > fair cpu scheduler with virtual cpus (runqueues). Linux-vserver uses > tocken bucket algorithm. I can provide more details on this if you are > interested.
Yes, any information or pointers to them will be very useful.
> - cpu limits (soft, hard). OpenVZ provides only hard cpu limits. For > this we account the time in cycles. And after some credit is used do > delay of container execution. We use cycles as our experiments show that > statistical algorithms work poorly on some patterns :( > - cpu guarantees. I'm not sure any of solutions provide this yet.
ckrm has a solution to provide cpu guarantees.
I think as far as CPU resource management is concerned (limits or guarantees), there are common problems to be solved, for example
1. Tracking when a limit or a gaurantee is not met 2. Taking a decision to cap the group 3. Selecting the next task to execute (keeping O(1) in mind)
For the existing resource controller in OpenVZ I would be interested in the information on the kinds of patterns it does not perform well on and the patterns it performs well on.
> > 2) disk: > - overall disk quota for container > - per-user/group quotas inside container > > in OpenVZ we wrote a 2level disk quota which works on disk subtrees. > vserver imho uses 1 partition per container approach. > > - disk I/O bandwidth: > we started to use CFQv2, but it is quite poor in this regard. First, it > doesn't prioritizes writes and async disk operations :( And even for > sync reads we found some problems we work on now... > > 3) memory and other resources. > - memory > - files > - signals and so on and so on. > For example, in OpenVZ we have user resource beancounters (original > author is Alan Cox), which account the following set of parameters: > kernel memory (vmas, page tables, different structures etc.), dcache > pinned size, different user pages (locked, physical, private, shared), > number of files, sockets, ptys, signals, network buffers, netfilter > rules etc. > > 4. network bandwidth > traffic shaping is already ok here.
Traffic shaping is just for outgoing traffic right? How about incoming traffic (through the accept call)
>
These are a great set of requirements. Thanks for putting them together.
>> Thinking a bit more along these lines, it would probably break O(1). >> But I guess a good >> algorithm can amortize the cost. > > this is the price to pay. but it happens quite rarelly as was noticed > already... >
Yes, agreed.
> Kirill >
--
Balbir Singh, Linux Technology Center, IBM Software Labs
PS: I am also cc'ing ckrm-tech and srivatsa - 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/
| |