OpenVZ Forum


Home » Mailing lists » Devel » Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction
Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction [message #6627] Wed, 20 September 2006 20:49 Go to next message
Paul Jackson is currently offline  Paul Jackson
Messages: 157
Registered: February 2006
Senior Member
Paul M wrote:
> Even if the resource control portions aren't totally compatible,
> having two separate process container abstractions in the kernel is
> sub-optimal

At heart, CKRM (ne Resource Groups) are (well, have been until now)
different than cpusets.

Cpusets answers the question 'where', and Resource Groups 'how much'.

The fundamental motivation behind cpusets was to be able to enforce
job isolation. A job can get dedicated use of specified resources,
-even- if it means those resources are severely underutilized by that
job.

The fundamental motivation (Chandra or others correct me if I'm wrong)
of Resource Groups is to improve capacity utilization while limiting
starvation due to greedy, competing users for the same resources.

Cpusets seeks maximum isolation. Resource Groups seeks maximum
capacity utilization while preserving guaranteed levels of quality
of service.

Cpusets are that wall between you and the neighbor you might not
trust. Resource groups are a large family of modest wealth sitting
down to share a meal.

It seems that cpusets can mimic memory resource groups. I don't
see how cpusets could mimic other resource groups. But maybe I'm
just being a dimm bulb.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction [message #6658 is a reply to message #6627] Thu, 21 September 2006 00:45 Go to previous messageGo to next message
Chandra Seetharaman is currently offline  Chandra Seetharaman
Messages: 88
Registered: August 2006
Member
On Wed, 2006-09-20 at 13:49 -0700, Paul Jackson wrote:

I concur with most of the comments (except as noted below)
> Paul M wrote:
> > Even if the resource control portions aren't totally compatible,
> > having two separate process container abstractions in the kernel is
> > sub-optimal
>
> At heart, CKRM (ne Resource Groups) are (well, have been until now)
> different than cpusets.
>
> Cpusets answers the question 'where', and Resource Groups 'how much'.
>
> The fundamental motivation behind cpusets was to be able to enforce
> job isolation. A job can get dedicated use of specified resources,
> -even- if it means those resources are severely underutilized by that
> job.
>
> The fundamental motivation (Chandra or others correct me if I'm wrong)
> of Resource Groups is to improve capacity utilization while limiting
> starvation due to greedy, competing users for the same resources.
>
> Cpusets seeks maximum isolation. Resource Groups seeks maximum
> capacity utilization while preserving guaranteed levels of quality
> of service.
>
> Cpusets are that wall between you and the neighbor you might not
> trust. Resource groups are a large family of modest wealth sitting
> down to share a meal.

I am thinking hard about how to bring guarantee into this picture :).

>
> It seems that cpusets can mimic memory resource groups. I don't

I am little confused w.r.t how cpuset can mimic memory resource groups.
How can cpuset provide support for over commit.

> see how cpusets could mimic other resource groups. But maybe I'm
> just being a dimm bulb.
>
--

------------------------------------------------------------ ----------
Chandra Seetharaman | Be careful what you choose....
- sekharan@us.ibm.com | .......you may get it.
------------------------------------------------------------ ----------
Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction [message #6661 is a reply to message #6658] Thu, 21 September 2006 00:51 Go to previous message
Paul Jackson is currently offline  Paul Jackson
Messages: 157
Registered: February 2006
Senior Member
Chandra wrote:
> > It seems that cpusets can mimic memory resource groups. I don't
>
> I am little confused w.r.t how cpuset can mimic memory resource groups.
> How can cpuset provide support for over commit.

I didn't say "mimic well" ;).

I had no clue cpusets could do overcommit at all, though Paul Menage just
posted a notion of how to mimic overcommit, with his post beginning:

> I have some patches locally that basically let you give out a small
> set of nodes initially to a cpuset, and if memory pressure in
> try_to_free_pages() passes a specified threshold, automatically
> allocate one of the parent cpuset's unused memory nodes to the child
> cpuset, up to specified limit.

--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@sgi.com> 1.925.600.0401
Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction [message #6743 is a reply to message #6627] Wed, 20 September 2006 20:51 Go to previous message
Paul Menage is currently offline  Paul Menage
Messages: 642
Registered: September 2006
Senior Member
On 9/20/06, Paul Jackson <pj@sgi.com> wrote:
>
> It seems that cpusets can mimic memory resource groups. I don't
> see how cpusets could mimic other resource groups. But maybe I'm
> just being a dimm bulb.
>

I'm not saying that they can - but they could be parallel types of
resource controller for a generic container abstraction, so that
userspace can create a container, and use e.g. memory node isolation
from the cpusets code in conjunction with the resource groups %-based
CPU scheduler.

Paul
Previous Topic: Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction
Next Topic: Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction
Goto Forum:
  


Current Time: Fri Nov 01 23:26:38 GMT 2024

Total time taken to generate the page: 0.04569 seconds