> ...
> For implementing guarantees, we can use limits. Please see
> http://wiki.openvz.org/Containers/Guarantees_for_resources.
Nack.
This seems to be correct for resources like cpu, disk or network
bandwidth but not for the memory just because nobody in this wiki
speaks about the kswapd and page reclaim (but it's true that a such
demon does not exist for cpu, disk or... then the problem is more
simple).
For a customer the main reason to use guarantee is to be sure that
some pages of a job remain in memory when the system is low on free
memory. This should be true even for a job in group/container A with
a smooth activity compared to a group/container B with a set of jobs
using memory more agressively...
What happens if we use limits to implement guarantees ?
>> ...
>> The idea of getting a guarantee is simple:
>> if any group gi requires a Gi units of resource from R units available
>> then limiting all the rest groups with R - Gi units provides a desired
>> guarantee
If the limit is a "hard limit" then we have implemented reservation and
this is too strict.
If the limit is a "soft limit" then group/container B is autorized to
use more than the limit and nothing is guaranteed for group/container A...
Patrick
On Fri, 17 Nov 2006 14:25:33 +0100 (CET)
> For a customer the main reason to use guarantee is to be sure that
> some pages of a job remain in memory when the system is low on free
> memory. This should be true even for a job in group/container A with
That actually doesn't appear a very useful definition.
There are two reasons for wanting memory guarantees
#1 To be sure a user can't toast the entire box but just their own
compartment (eg web hosting)
#2 To ensure all apps continue to make progress
The simple approach doesn't seem to work for either. There is a threshold
above which #1 and #2 are the same thing, below that trying to keep a few
pages in memory will thrash not make progress and will harm overall
behaviour thus failing to solve #1 or #2. At that point you have to
decide whether what you have is a misconfiguration or whether the system
should be prepared to do temporary cycling overcommits so containers take
it in turn to make progress when overcommitted.
> If the limit is a "hard limit" then we have implemented reservation and
> this is too strict.
Thats fundamentally a judgement based on your particular workload and
constraints. If I am web hosting then I don't generally care if my end
users compartment blows up under excess load, I care that the other 200
customers using the box don't suffer and all phone me to complain.
Alan
Patrick.Le-Dot wrote:
>> ...
>> For implementing guarantees, we can use limits. Please see
>> http://wiki.openvz.org/Containers/Guarantees_for_resources.
>
> Nack.
>
> This seems to be correct for resources like cpu, disk or network
> bandwidth but not for the memory just because nobody in this wiki
> speaks about the kswapd and page reclaim (but it's true that a such
> demon does not exist for cpu, disk or... then the problem is more
> simple).
>
> For a customer the main reason to use guarantee is to be sure that
> some pages of a job remain in memory when the system is low on free
> memory. This should be true even for a job in group/container A with
> a smooth activity compared to a group/container B with a set of jobs
> using memory more agressively...
>
I am not against guarantees, but
Consider the following scenario, let's say we implement guarantees
1. If we account for kernel resources, how do you provide guarantees
when you have non-reclaimable resources?
2. If a customer runs a system with swap turned off (which is quite
common), then anonymous memory becomes irreclaimable. If a group
takes more than it's fair share (exceeds its guarantee), you
have scenario similar to 1 above.
> What happens if we use limits to implement guarantees ?
>
>>> ...
>>> The idea of getting a guarantee is simple:
>>> if any group gi requires a Gi units of resource from R units available
>>> then limiting all the rest groups with R - Gi units provides a desired
>>> guarantee
>
> If the limit is a "hard limit" then we have implemented reservation and
> this is too strict.
>
> If the limit is a "soft limit" then group/container B is autorized to
> use more than the limit and nothing is guaranteed for group/container A...
>
> Patrick
Yes, but it is better than failing to meet a guarantee (if guarantees are
desired :))
--
Balbir Singh,
Linux Technology Center,
IBM Software Labs