On Thu, Mar 22, 2007 at 09:39:09AM -0500, Serge E. Hallyn wrote:
> > What troubles will mounting both cpuset and ns in the same hierarchy
> > cause?
>
> Wow, don't recall the full context here.
Sorry to have come back so late on this :)
> But at least with Paul's container patchset, a subsystem
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Fri, Mar 09, 2007 at 10:50:17AM -0600, Serge E. Hallyn wrote:
> > The nsproxy container subsystem could be said to be that unification.
> > If we really wanted to I suppose we could now always mount the nsproxy
> > subsystem, get rid of
On Fri, Mar 09, 2007 at 10:50:17AM -0600, Serge E. Hallyn wrote:
> The nsproxy container subsystem could be said to be that unification.
> If we really wanted to I suppose we could now always mount the nsproxy
> subsystem, get rid of tsk->nsproxy, and always get thta through it's
> nsproxy
On Fri, Mar 09, 2007 at 10:50:17AM -0600, Serge E. Hallyn wrote:
The nsproxy container subsystem could be said to be that unification.
If we really wanted to I suppose we could now always mount the nsproxy
subsystem, get rid of tsk-nsproxy, and always get thta through it's
nsproxy subsystem
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Fri, Mar 09, 2007 at 10:50:17AM -0600, Serge E. Hallyn wrote:
The nsproxy container subsystem could be said to be that unification.
If we really wanted to I suppose we could now always mount the nsproxy
subsystem, get rid of tsk-nsproxy,
On Thu, Mar 22, 2007 at 09:39:09AM -0500, Serge E. Hallyn wrote:
What troubles will mounting both cpuset and ns in the same hierarchy
cause?
Wow, don't recall the full context here.
Sorry to have come back so late on this :)
But at least with Paul's container patchset, a subsystem can
On Mon, Mar 12, 2007 at 07:25:48PM -0700, Paul Menage wrote:
> On 3/12/07, Herbert Poetzl <[EMAIL PROTECTED]> wrote:
> >
> > why? you simply enter that specific space and
> > use the existing mechanisms (netlink, proc, whatever)
> > to retrieve the information with _existing_ tools,
>
> That's
On Mon, Mar 12, 2007 at 07:25:48PM -0700, Paul Menage wrote:
On 3/12/07, Herbert Poetzl [EMAIL PROTECTED] wrote:
why? you simply enter that specific space and
use the existing mechanisms (netlink, proc, whatever)
to retrieve the information with _existing_ tools,
That's assuming that
On 3/12/07, Herbert Poetzl <[EMAIL PROTECTED]> wrote:
why? you simply enter that specific space and
use the existing mechanisms (netlink, proc, whatever)
to retrieve the information with _existing_ tools,
That's assuming that you're using network namespace virtualization,
with each group of
On Tue, Mar 13, 2007 at 12:31:13AM +0100, Herbert Poetzl wrote:
> just means that the current Linux-VServer behaviour
> is a subset of that, no problem there as long as
> it really _is_ a subset :) we always like to provide
> more features in the future, no problem with that :)
Considering the
On Mon, Mar 12, 2007 at 09:50:45PM +0530, Srivatsa Vaddagiri wrote:
> On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
> > What's wrong with that?
>
> I had been asking around on "what is the fundamental unit of res mgmt
> for vservers" and the answer I got (from Herbert) was "all
On Mon, Mar 12, 2007 at 03:00:25AM -0700, Paul Menage wrote:
> On 3/11/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> >
> > My current understanding of Paul Menage's container patch is that it is
> > a useful improvement for some of the metered classes - those that could
> > make good use of a file
Srivatsa Vaddagiri wrote:
> On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
>
>> What's wrong with that?
>>
>
> I had been asking around on "what is the fundamental unit of res mgmt
> for vservers" and the answer I got (from Herbert) was "all tasks that are
> in the same
vatsa wrote:
> This assumes that you can see the global vfs namespace right?
>
> What if you are inside a container/vserver which restricts your vfs
> namespace? i.e /dev/cpusets seen from one container is not same as what
> is seen from another container .
Well, yes. But that restriction on
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
> > What's wrong with that?
>
> I had been asking around on "what is the fundamental unit of res mgmt
> for vservers" and the answer I got (from Herbert) was "all tasks that are
> in
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
> What's wrong with that?
I had been asking around on "what is the fundamental unit of res mgmt
for vservers" and the answer I got (from Herbert) was "all tasks that are
in the same pid namespace". From what you are saying above, it
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
> On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
> > > 3. This next leads me to think that 'tasks' file in each directory doesnt
> > > make
> > >sense for containers. In fact it can lend itself to error situations
> > > (by
> > >
On Mon, Mar 12, 2007 at 07:31:48PM +0530, Srivatsa Vaddagiri wrote:
> not so. This in-fact lets vservers and containers to work with each
> other. So:
s/containers/cpusets
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
> > 3. This next leads me to think that 'tasks' file in each directory doesnt
> > make
> >sense for containers. In fact it can lend itself to error situations (by
> >administrator/script mistake) when some tasks of a container
On Wed, Mar 07, 2007 at 03:59:19PM -0600, Serge E. Hallyn wrote:
> > containers patches uses just a single pointer in the task_struct, and
> > all tasks in the same set of containers (across all hierarchies) will
> > share a single container_group object, which holds the actual pointers
> > to
On Fri, Mar 09, 2007 at 02:06:03PM -0800, Paul Jackson wrote:
> > if you create a 'resource container' to limit the
> > usage of a set of resources for the processes
> > belonging to this container, it would be kind of
> > defeating the purpose, if you'd allow the processes
> > to manipulate
On 3/11/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
My current understanding of Paul Menage's container patch is that it is
a useful improvement for some of the metered classes - those that could
make good use of a file system like hierarchy for their interface.
It probably doesn't benefit all
Allow me to annotate your nice summary. A lot of this is elaborating on
what you are saying; and I think where we disagree, the differences are
not important.
Paul Jackson wrote:
> We have actors, known as threads, tasks or processes, which use things,
> which are instances of such classes of
Allow me to annotate your nice summary. A lot of this is elaborating on
what you are saying; and I think where we disagree, the differences are
not important.
Paul Jackson wrote:
We have actors, known as threads, tasks or processes, which use things,
which are instances of such classes of
On 3/11/07, Paul Jackson [EMAIL PROTECTED] wrote:
My current understanding of Paul Menage's container patch is that it is
a useful improvement for some of the metered classes - those that could
make good use of a file system like hierarchy for their interface.
It probably doesn't benefit all
On Fri, Mar 09, 2007 at 02:06:03PM -0800, Paul Jackson wrote:
if you create a 'resource container' to limit the
usage of a set of resources for the processes
belonging to this container, it would be kind of
defeating the purpose, if you'd allow the processes
to manipulate their
On Wed, Mar 07, 2007 at 03:59:19PM -0600, Serge E. Hallyn wrote:
containers patches uses just a single pointer in the task_struct, and
all tasks in the same set of containers (across all hierarchies) will
share a single container_group object, which holds the actual pointers
to container
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
3. This next leads me to think that 'tasks' file in each directory doesnt
make
sense for containers. In fact it can lend itself to error situations (by
administrator/script mistake) when some tasks of a container are in
On Mon, Mar 12, 2007 at 07:31:48PM +0530, Srivatsa Vaddagiri wrote:
not so. This in-fact lets vservers and containers to work with each
other. So:
s/containers/cpusets
--
Regards,
vatsa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Fri, Mar 09, 2007 at 02:09:35PM -0800, Paul Menage wrote:
3. This next leads me to think that 'tasks' file in each directory doesnt
make
sense for containers. In fact it can lend itself to error situations
(by
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
What's wrong with that?
I had been asking around on what is the fundamental unit of res mgmt
for vservers and the answer I got (from Herbert) was all tasks that are
in the same pid namespace. From what you are saying above, it
Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
What's wrong with that?
I had been asking around on what is the fundamental unit of res mgmt
for vservers and the answer I got (from Herbert) was all tasks that are
in the same
vatsa wrote:
This assumes that you can see the global vfs namespace right?
What if you are inside a container/vserver which restricts your vfs
namespace? i.e /dev/cpusets seen from one container is not same as what
is seen from another container .
Well, yes. But that restriction on the
Srivatsa Vaddagiri wrote:
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
What's wrong with that?
I had been asking around on what is the fundamental unit of res mgmt
for vservers and the answer I got (from Herbert) was all tasks that are
in the same pid namespace.
On Mon, Mar 12, 2007 at 03:00:25AM -0700, Paul Menage wrote:
On 3/11/07, Paul Jackson [EMAIL PROTECTED] wrote:
My current understanding of Paul Menage's container patch is that it is
a useful improvement for some of the metered classes - those that could
make good use of a file system
On Mon, Mar 12, 2007 at 09:50:45PM +0530, Srivatsa Vaddagiri wrote:
On Mon, Mar 12, 2007 at 10:56:43AM -0500, Serge E. Hallyn wrote:
What's wrong with that?
I had been asking around on what is the fundamental unit of res mgmt
for vservers and the answer I got (from Herbert) was all tasks
On Tue, Mar 13, 2007 at 12:31:13AM +0100, Herbert Poetzl wrote:
just means that the current Linux-VServer behaviour
is a subset of that, no problem there as long as
it really _is_ a subset :) we always like to provide
more features in the future, no problem with that :)
Considering the
On 3/12/07, Herbert Poetzl [EMAIL PROTECTED] wrote:
why? you simply enter that specific space and
use the existing mechanisms (netlink, proc, whatever)
to retrieve the information with _existing_ tools,
That's assuming that you're using network namespace virtualization,
with each group of
Sam, responding to Herbert:
> > from my personal PoV the following would be fine:
> >
> > spaces (for the various 'spaces')
> >...
> > container (for resource accounting/limits)
> >...
>
> I like these a lot ...
Hmmm ... ok ...
Let me see if I understand this.
We have actors, known
Sam, responding to Herbert:
from my personal PoV the following would be fine:
spaces (for the various 'spaces')
...
container (for resource accounting/limits)
...
I like these a lot ...
Hmmm ... ok ...
Let me see if I understand this.
We have actors, known as threads,
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
-
Herbert Poetzl wrote:
> On Wed, Mar 07, 2007 at 11:44:58PM -0700, Eric W. Biederman wrote:
>
>> I really don't much care as long as we don't start redefining
>> container as something else. I think the IBM guys took it from
>> solaris originally which seems to define a zone as a set of
>>
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
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 change the mapping
Herbert Poetzl wrote:
On Wed, Mar 07, 2007 at 11:44:58PM -0700, Eric W. Biederman wrote:
I really don't much care as long as we don't start redefining
container as something else. I think the IBM guys took it from
solaris originally which seems to define a zone as a set of
isolated
Sam wrote:
But when you apply this to something like cpusets, it gets a little abstract.
Just a tad abstract grin.
Thanks.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson [EMAIL PROTECTED] 1.925.600.0401
-
On Sat, Mar 10, 2007 at 07:32:20AM +0530, Srivatsa Vaddagiri wrote:
> Ok, let me see if I can convey what I had in mind better:
>
> uts_ns pid_ns ipc_ns
> \|/
> ---
> | nsproxy|
>
>
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
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
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
> the emphasis here is on 'from inside' which basically
> boils down to the following:
>
> if you create a 'resource container' to limit the
> usage of a set of resources for the processes
> belonging to this container, it would be kind of
> defeating the purpose, if you'd allow the processes
On Fri, Mar 09, 2007 at 11:49:08PM +0530, Srivatsa Vaddagiri wrote:
> On Fri, Mar 09, 2007 at 01:53:57AM +0100, Herbert Poetzl wrote:
>>> The real trick is that I believe these groupings are designed to
>>> be something you can setup on login and then not be able to switch
>>> out of. Which means
Herbert wrote (and vatsa quoted):
> precisely, once you are inside a resource container, you
> must not have the ability to modify its limits, and to
> some degree, you should not know about the actual available
> resources, but only about the artificial limits
Not necessarily. Depending on the
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
On Fri, Mar 09, 2007 at 01:53:57AM +0100, Herbert Poetzl wrote:
> > The real trick is that I believe these groupings are designed to
> > be something you can setup on login and then not be able to switch
> > out of. Which means we can't use sessions and process groups as the
> > grouping entities
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
> >
> >Ok, they share this characteristic with namespaces: that they group
> >processes.
Namespaces have a side effect of grouping processes, but a namespace is
not defined by 'grouping proceses.' A
On Fri, Mar 09, 2007 at 10:04:30PM +0530, Srivatsa Vaddagiri wrote:
> 2. Regarding space savings, if 100 tasks are in a container (I dont know
>what is a typical number) -and- lets say that all tasks are to share
>the same resource allocation (which seems to be natural), then having
>a
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
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 issue, then
On Fri, Mar 09, 2007 at 10:04:30PM +0530, Srivatsa Vaddagiri wrote:
2. Regarding space savings, if 100 tasks are in a container (I dont know
what is a typical number) -and- lets say that all tasks are to share
the same resource allocation (which seems to be natural), then having
a
Quoting Paul Menage ([EMAIL PROTECTED]):
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
Ok, they share this characteristic with namespaces: that they group
processes.
Namespaces have a side effect of grouping processes, but a namespace is
not defined by 'grouping proceses.' A container is,
On Fri, Mar 09, 2007 at 01:53:57AM +0100, Herbert Poetzl wrote:
The real trick is that I believe these groupings are designed to
be something you can setup on login and then not be able to switch
out of. Which means we can't use sessions and process groups as the
grouping entities as those
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 to
Herbert wrote (and vatsa quoted):
precisely, once you are inside a resource container, you
must not have the ability to modify its limits, and to
some degree, you should not know about the actual available
resources, but only about the artificial limits
Not necessarily. Depending on the
On Fri, Mar 09, 2007 at 11:49:08PM +0530, Srivatsa Vaddagiri wrote:
On Fri, Mar 09, 2007 at 01:53:57AM +0100, Herbert Poetzl wrote:
The real trick is that I believe these groupings are designed to
be something you can setup on login and then not be able to switch
out of. Which means we can't
the emphasis here is on 'from inside' which basically
boils down to the following:
if you create a 'resource container' to limit the
usage of a set of resources for the processes
belonging to this container, it would be kind of
defeating the purpose, if you'd allow the processes
to
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
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
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 namespaces
On Sat, Mar 10, 2007 at 07:32:20AM +0530, Srivatsa Vaddagiri wrote:
Ok, let me see if I can convey what I had in mind better:
uts_ns pid_ns ipc_ns
\|/
---
| nsproxy|
Matt wrote:
> It's like that Star Trek episode ... except we can't agree on the name
Usually, when there is this much heat and smoke over a name, there is
really an underlying disagreement or misunderstanding over the meaning
of something.
The name becomes the proxy for meaning ;).
--
> The real trick is that I believe these groupings are designed to be something
> you can setup on login and then not be able to switch out of. Which means
> we can't use sessions and process groups as the grouping entities as those
> have different semantics.
Not always on login. For big
> 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
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
>
On Wed, Mar 07, 2007 at 11:44:58PM -0700, Eric W. Biederman wrote:
> Matt Helsley <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2007-03-08 at 16:32 +-1300, Sam Vilain wrote:
> >
> > +ADw-snip+AD4
> >
> > +AD4 Kirill, 06032418:36+-03:
> > +AD4 +AD4 I propose to use +ACI-namespace+ACI naming.
> > +AD4
On Wed, Mar 07, 2007 at 05:35:58PM -0800, Paul Menage wrote:
> On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> Pretty much. For most of the other cases I think we are safe
>> referring to them as resource controls or resource limits. I know
>> that roughly covers what cpusets and
On Wed, Mar 07, 2007 at 06:32:10PM -0700, Eric W. Biederman wrote:
> "Paul Menage" <[EMAIL PROTECTED]> writes:
>
>> On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
>>> But "namespace" has well-established historical semantics too - a way
>>> of changing the mappings of local * to global objects.
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
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
On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Ok, they share this characteristic with namespaces: that they group
processes. So, they conceptually hang off task_struct. But we put them
on ns_proxy because we've got this vague notion that things might be
better that way.
Remember that I'm
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
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
On Wed, Mar 07, 2007 at 06:32:10PM -0700, Eric W. Biederman wrote:
Paul Menage [EMAIL PROTECTED] writes:
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
But namespace has well-established historical semantics too - a way
of changing the mappings of local * to global objects. This
accurately
On Wed, Mar 07, 2007 at 05:35:58PM -0800, Paul Menage wrote:
On 3/7/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Pretty much. For most of the other cases I think we are safe
referring to them as resource controls or resource limits. I know
that roughly covers what cpusets and beancounters
On Wed, Mar 07, 2007 at 11:44:58PM -0700, Eric W. Biederman wrote:
Matt Helsley [EMAIL PROTECTED] writes:
On Thu, 2007-03-08 at 16:32 +-1300, Sam Vilain wrote:
+ADw-snip+AD4
+AD4 Kirill, 06032418:36+-03:
+AD4 +AD4 I propose to use +ACI-namespace+ACI naming.
+AD4 +AD4 1. This is
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
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 you
The real trick is that I believe these groupings are designed to be something
you can setup on login and then not be able to switch out of. Which means
we can't use sessions and process groups as the grouping entities as those
have different semantics.
Not always on login. For big
Matt wrote:
It's like that Star Trek episode ... except we can't agree on the name
Usually, when there is this much heat and smoke over a name, there is
really an underlying disagreement or misunderstanding over the meaning
of something.
The name becomes the proxy for meaning ;).
--
On 3/7/07, Sam Vilain [EMAIL PROTECTED] wrote:
Ok, they share this characteristic with namespaces: that they group
processes. So, they conceptually hang off task_struct. But we put them
on ns_proxy because we've got this vague notion that things might be
better that way.
Remember that I'm
Matt Helsley <[EMAIL PROTECTED]> writes:
> On Thu, 2007-03-08 at 16:32 +-1300, Sam Vilain wrote:
>
> +ADw-snip+AD4
>
> +AD4 Kirill, 06032418:36+-03:
> +AD4 +AD4 I propose to use +ACI-namespace+ACI naming.
> +AD4 +AD4 1. This is already used in fs.
> +AD4 +AD4 2. This is what IMHO suites at least
Sam Vilain <[EMAIL PROTECTED]> writes:
> And do we bother changing IPC namespaces or let that one slide?
ipc namespaces works (if you worry about tiny details like we put
the resource limits for the sysv ipc objects inside the namespace).
Probably the most instructive example of this is that
On Thu, 2007-03-08 at 16:32 +1300, Sam Vilain wrote:
> Kirill, 06032418:36+03:
> > I propose to use "namespace" naming.
> > 1. This is already used in fs.
> > 2. This is what IMHO suites at least OpenVZ/Eric
> > 3. it has good acronym "ns".
>
> Right. So, now I'll also throw into the mix:
>
Paul Menage wrote:
> I made sure to check [...]wikipedia.org[...] when this argument started ...
> :-)
>
Wikipedia?! That's not a referen[...]
oh bugger it. I've vented enough today and we're on the same page now I
think.
>> This is the classic terminology problem between substance and
On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Sorry, I didn't realise I was talking with somebody qualified enough to
speak on behalf of the Generally Established Principles of Computer Science.
I made sure to check
http://en.wikipedia.org/wiki/Namespace
Paul Menage wrote:
> Sorry, I think this statement is wrong, by the generally established
> meaning of the term namespace in computer science.
>
Sorry, I didn't realise I was talking with somebody qualified enough to
speak on behalf of the Generally Established Principles of Computer Science.
"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>> The real trick is that I believe these groupings are designed to be something
>> you can setup on login and then not be able to switch out of.
>
> That's going to to be the case for most
On 3/7/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
Pretty much. For most of the other cases I think we are safe referring
to them as resource controls or resource limits.I know that roughly covers
what cpusets and beancounters and ckrm currently do.
Plus resource monitoring (which
"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> 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,
On 3/7/07, Sam Vilain <[EMAIL PROTECTED]> 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.
Sorry, I think this
1 - 100 of 184 matches
Mail list logo
