| Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction [message #6723] |
Fri, 22 September 2006 00:06  |
Chandra Seetharaman
Messages: 88
Registered: August 2006
|
Member |
|
|
On Thu, 2006-09-21 at 15:09 -0700, Paul Menage wrote:
> On 9/21/06, Chandra Seetharaman <sekharan@us.ibm.com> wrote:
> >
> > >
> > > But, there's no reason that the OpenVZ resource control mechanisms
> > > couldn't be hooked into a generic process container mechanism along
> > > with cpusets and RG.
> >
> > Isn't that one of the things we are trying to avoid (each one having
> > their own solution, especially when we _can_ have a common solution).
>
> Can we actually have a single common solution that works for everyone,
> no matter what their needs? It's already apparent that there are
> multiple different and subtly incompatible definitions of what "memory
> controller" means and needs to do. Maybe these can be resolved - but
> maybe it's better to have, say, two simple but very different memory
> controllers that the user can pick between, rather than one big and
> complicated one that tries to please everyone.
Paul,
Think about what will be available to customer through a distro.
There are two (competing) memory controllers in the kernel. But, distro
can turn only one ON. Which in turn mean
- there will be a debate from the two controller users/advocates with
the distro (headache to distro) about which one to turn ON
- one party will _not_ get what they want and hence no point in them
getting the feature into the mainline in the first place
(dissatisfaction of the users/original implementors of one solution).
So, IMHO, it is better to sort out the differences before we get things
in mainline kernel.
>
> Paul
--
------------------------------------------------------------ ----------
Chandra Seetharaman | Be careful what you choose....
- sekharan@us.ibm.com | .......you may get it.
------------------------------------------------------------ ----------
|
|
|
|
|
|
|
|
|
|
| Re: [ckrm-tech] [patch00/05]: Containers(V2)- Introduction [message #6751 is a reply to message #6723] |
Fri, 22 September 2006 00:13  |
Paul Menage
Messages: 642
Registered: September 2006
|
Senior Member |
|
|
On 9/21/06, Chandra Seetharaman <sekharan@us.ibm.com> wrote:
> Think about what will be available to customer through a distro.
>
> There are two (competing) memory controllers in the kernel. But, distro
> can turn only one ON. Which in turn mean
Why's that? I don't see why cpuset memory nodemasks can't coexist
with, say, the RG memory controller. They're attempting to solve
different problems, and I can see situations where you might want to
use both at once.
>
> So, IMHO, it is better to sort out the differences before we get things
> in mainline kernel.
Agreed, if we can come up with a definition of e.g. memory controller
that everyone agrees is suitable for their needs. You're assuming
that's so a priori, I'm not yet convinced.
And I'm not trying to get another memory controller into the kernel,
I'm just trying to get a standard process aggregation into the kernel
(or rather, take the one that's already in the kernel and make it
possible to hook other controller frameworks into it), so that the
various memory controllers can become less intrusive patches in their
own right.
Paul
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
