lkml.org 
[lkml]   [2006]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC 3/5] sched: Add CPU rate hard caps
>>> The more runnable tasks there are the less likely it is that any of 
>>> them is exceeding its hard cap due to normal competition for the
>>> CPUs. So I think that it's unlikely that there will ever be a very
>>> large number of tasks in the sinbin at the same time.
>>
>>
>> for containers this can be untrue... :( actually even for 1000 tasks
>> (I suppose this is the maximum in your case) it can slowdown
>> significantly as well.
>
>
> 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 :(

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

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.

>>>> Is it possible to use the scheduler_tick() function take a look at all
>>>> deactivated tasks (as efficiently as possible) and activate them when
>>>> its time to activate them or just fold the functionality by defining a
>>>> time quantum after which everyone is worken up. This time quantum
>>>> could be the same as the time over which limits are honoured.
>>
>>
>> agree with it.
>
>
> 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...

Kirill

-
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-01 09:48    [W:0.168 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site