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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
