Sam wrote:
> But when you apply this to something like cpusets, it gets a little abstract.
Just a tad abstract .
Thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
T
Paul Jackson wrote:
>> But "namespace" has well-established historical semantics too - a way
>> of changing the mappings of local * to global objects. This
>> accurately describes things liek resource controllers, cpusets, resource
>> monitoring, etc.
>>
>
> No!
>
> Cpusets don't rename or cha
On Sat, Mar 10, 2007 at 12:11:05AM +0530, Srivatsa Vaddagiri wrote:
> On Fri, Mar 09, 2007 at 02:16:08AM +0100, Herbert Poetzl wrote:
> > On Thu, Mar 08, 2007 at 05:00:54PM +0530, Srivatsa Vaddagiri wrote:
> > > On Thu, Mar 08, 2007 at 01:50:01PM +1300, Sam Vilain wrote:
> > > > 7. resource namespa
I think maybe I didnt communicate what I mean by a container here
(although I thought I did). I am referring to a container in a vserver
context (set of tasks which share the same namespace).
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
> >2. Regarding space savings, if 100 tasks a
On 3/9/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
1. What is the fundamental unit over which resource-management is
applied? Individual tasks or individual containers?
/me thinks latter.
Yes
In which case, it makes sense to stick
resource control information in the co
On Fri, Mar 09, 2007 at 02:16:08AM +0100, Herbert Poetzl wrote:
> On Thu, Mar 08, 2007 at 05:00:54PM +0530, Srivatsa Vaddagiri wrote:
> > On Thu, Mar 08, 2007 at 01:50:01PM +1300, Sam Vilain wrote:
> > > 7. resource namespaces
> >
> > It should be. Imagine giving 20% bandwidth to a user X. X wants
On Wed, Mar 07, 2007 at 01:20:18PM -0800, Paul Menage wrote:
> On 3/7/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >
> >All that being said, if it were going to save space without overly
> >complicating things I'm actually not opposed to using nsproxy, but it
>
> If space-saving is the main is
> But "namespace" has well-established historical semantics too - a way
> of changing the mappings of local * to global objects. This
> accurately describes things liek resource controllers, cpusets, resource
> monitoring, etc.
No!
Cpusets don't rename or change the mapping of objects.
I suspect
On Thu, Mar 08, 2007 at 05:00:54PM +0530, Srivatsa Vaddagiri wrote:
> On Thu, Mar 08, 2007 at 01:50:01PM +1300, Sam Vilain wrote:
> > 7. resource namespaces
>
> It should be. Imagine giving 20% bandwidth to a user X. X wants to
> divide this bandwidth further between multi-media (10%), kernel
> co
On Wed, Mar 07, 2007 at 04:16:00PM -0700, Eric W. Biederman wrote:
> I think implementation wise this tends to make sense.
> However it should have nothing to do with semantics.
>
> If we have a lot of independent resource controllers. Placing the
> pointer to their data structures directly in ns
On Thu, Mar 08, 2007 at 01:50:01PM +1300, Sam Vilain wrote:
> 7. resource namespaces
It should be. Imagine giving 20% bandwidth to a user X. X wants to
divide this bandwidth further between multi-media (10%), kernel
compilation (5%) and rest (5%). So,
> Is the subservient namespace's resource usa
Paul Menage wrote:
> But "namespace" has well-established historical semantics too - a way
> of changing the mappings of local names to global objects. This
> doesn't describe things liek resource controllers, cpusets, resource
> monitoring, etc.
>
> Trying to extend the well-known term namespace t
Srivatsa Vaddagiri wrote:
> container structure in your patches provides for these things:
>
> a. A way to group tasks
> b. A way to maintain several hierarchies of such groups
>
> If you consider just a. then I agree that container abstraction is
> redundant, esp for vserver resource control (ns
On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Paul Menage wrote:
>> In the namespace world when we say container we mean roughly at the level
>> of nsproxy and container_group.
>>
> So you're saying that a task can only be in a single system-wide container.
>
Nope, we didn't make the mistake
Paul Menage wrote:
>> In the namespace world when we say container we mean roughly at the level
>> of nsproxy and container_group.
>>
> So you're saying that a task can only be in a single system-wide container.
>
Nope, we didn't make the mistake of nailing down what a "container" was
too
On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Effectively, container_group is to container as nsproxy is to namespace.
The statement above nicely summarizes the confusion in terminology.
In the namespace world when we say container we mean roughly at the level
of nsproxy and contain
"Paul Menage" <[EMAIL PROTECTED]> writes:
> No, Sam was saying that nsproxy should be the object that all resource
> controllers hook off.
I think implementation wise this tends to make sense.
However it should have nothing to do with semantics.
If we have a lot of independent resource controlle
Dave Hansen <[EMAIL PROTECTED]> writes:
> On Wed, 2007-03-07 at 15:59 -0600, Serge E. Hallyn wrote:
>> Space saving was the only reason for nsproxy to exist.
>>
>> Now of course it also provides the teensiest reduction in # instructions
>> since every clone results in just one reference count inc
"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 3/7/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
>>
>> All that being said, if it were going to save space without overly
>> complicating things I'm actually not opposed to using nsproxy, but it
>
> If space-saving is the main issue, then the latest
On Wed, 2007-03-07 at 15:59 -0600, Serge E. Hallyn wrote:
> Space saving was the only reason for nsproxy to exist.
>
> Now of course it also provides the teensiest reduction in # instructions
> since every clone results in just one reference count inc for the
> nsproxy rather than one for each nam
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 3/7/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >
> >All that being said, if it were going to save space without overly
> >complicating things I'm actually not opposed to using nsproxy, but it
>
> If space-saving is the main issue, then the latest
On 3/7/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
All that being said, if it were going to save space without overly
complicating things I'm actually not opposed to using nsproxy, but it
If space-saving is the main issue, then the latest version of my
containers patches uses just a single
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Wed, Mar 07, 2007 at 11:43:46AM -0600, Serge E. Hallyn wrote:
> > I still think the complaint was about terminology, not implementation.
>
> I don't think that is what http://lkml.org/lkml/2007/2/12/426 conveyed!
I don't have that in my inbox a
On Wed, Mar 07, 2007 at 11:43:46AM -0600, Serge E. Hallyn wrote:
> I still think the complaint was about terminology, not implementation.
I don't think that is what http://lkml.org/lkml/2007/2/12/426 conveyed!
> They just didn't want you calling them containers.
Yes that too.
> > Anyway, summar
On 3/7/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Tue, Mar 06, 2007 at 06:32:07PM -0800, Paul Menage wrote:
> > I'm not really sure that I see the value of having this be part of
> > nsproxy rather than the previous independent container (a
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Tue, Mar 06, 2007 at 06:32:07PM -0800, Paul Menage wrote:
> > I'm not really sure that I see the value of having this be part of
> > nsproxy rather than the previous independent container (and
> > container_group) structure.
>
> *shrug*
>
> I
On 3/7/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> - when you do sys_unshare() or a clone that creates new namespaces,
> then the task (or its child) will get a new nsproxy that has the rcfs
> subsystem state associated with the old nsproxy, and one or more
> namespace pointers cloned to
On Wed, Mar 07, 2007 at 11:00:31PM +0530, Srivatsa Vaddagiri wrote:
> So we got several choices here.
>
> 1. Introduce the container abstraction as is in your patches
> 2. Extend nsproxy somehow to represent hierarchies
> 3. Let individual resource controllers that -actually- support
>hierarch
On Tue, Mar 06, 2007 at 06:32:07PM -0800, Paul Menage wrote:
> I'm not really sure that I see the value of having this be part of
> nsproxy rather than the previous independent container (and
> container_group) structure.
*shrug*
I wrote the patch mainly to see whether the stuff container folks
Hi Vatsa,
Sorry for the delayed reply - the last week has been very busy ...
On 3/1/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
Paul,
Based on some of the feedback to container patches, I have
respun them to avoid the "container" structure abstraction and instead use
nsproxy struc
On Sat, Mar 03, 2007 at 01:22:44PM -0800, Paul Jackson wrote:
> I still can't claim to have my head around this, but what you write
> here, Herbert, writes here touches on what I suspect is a key
> difference between namespaces and resources that would make it
> impractical to accomplish both with
On Sat, Mar 03, 2007 at 02:21:00AM -0800, Paul Jackson wrote:
> Perhaps you could summarize what becomes of this hook, in this
> brave new world of rcfs ...
attach_task() still uses a synchronize_rcu before doing a put_nsproxy in
the rcfs patches. This means cpuset_update_task_memory_state() can r
Herbert wrote:
> I agree here, there is not much difference for the
> following aspects:
Whether two somewhat similar needs should be met by one shared
mechanism, or two distinct mechanisms, cannot really be decided by
listing the similarities.
One has to determine if there are any significant di
On Fri, Mar 02, 2007 at 06:45:06PM +0300, Kirill Korotaev wrote:
> Paul,
>
> >>I suspect we can make cpusets also work
> >>on top of this very easily.
> >
> >
> > I'm skeptical, and kinda worried.
> >
> > ... can you show me the code that does this?
> don't worry. we are not planning to commit
On Sat, Mar 03, 2007 at 03:06:55PM +0530, Srivatsa Vaddagiri wrote:
> On Thu, Mar 01, 2007 at 11:39:00AM -0800, Paul Jackson wrote:
> > vatsa wrote:
> > > I suspect we can make cpusets also work
> > > on top of this very easily.
> >
> > I'm skeptical, and kinda worried.
> >
> > ... can you show m
> Regarding semantics, can you be more specific?
Unfortunately not - sorry.
I've been off in other areas, and not found the time
to read through this current PATCH or think about it
carefully enough to be really useful.
Your reply seemed reasonable enough.
> It should have the same perf overhea
On Thu, Mar 01, 2007 at 11:39:00AM -0800, Paul Jackson wrote:
> vatsa wrote:
> > I suspect we can make cpusets also work
> > on top of this very easily.
>
> I'm skeptical, and kinda worried.
>
> ... can you show me the code that does this?
In essense, the rcfs patch is same as the original conta
Andrew,
>>>I'm wagering you'll break either the semantics, and/or the
>>>performance, of cpusets doing this.
>>
>>I like Paul's containers patch. It looks good and pretty well.
>>After some of the context issues are resolved it's fine.
>>Maybe it is even the best way of doing things.
>
>
> Have
On Fri, 02 Mar 2007 18:45:06 +0300 Kirill Korotaev <[EMAIL PROTECTED]> wrote:
> > I'm wagering you'll break either the semantics, and/or the
> > performance, of cpusets doing this.
> I like Paul's containers patch. It looks good and pretty well.
> After some of the context issues are resolved it's
Paul,
>>I suspect we can make cpusets also work
>>on top of this very easily.
>
>
> I'm skeptical, and kinda worried.
>
> ... can you show me the code that does this?
don't worry. we are not planning to commit any code breaking cpusets...
I will be the first one against it.
> Namespaces are no
vatsa wrote:
> I suspect we can make cpusets also work
> on top of this very easily.
I'm skeptical, and kinda worried.
... can you show me the code that does this?
Namespaces are not the same thing as actual resources
(memory, cpu cycles, ...). Namespaces are fluid mappings;
Resources are scarc
41 matches
Mail list logo
