Quoting Sam Vilain ([EMAIL PROTECTED]):
> Paul Menage wrote:
> We talked about naming a bit before, see
> http://lkml.org/lkml/2006/3/21/403 and possibly other threads. So,
> anyway, feel free to flog this old dead horse and suggest different
> terms. We've all had long enough to think about it
On 2/20/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Paul Menage wrote:
>> No. A reverse mapping is not needed and is not interesting.
>>
> ... to you.
>
You're missing the point of Eric's next sentence. If you can achieve
everything you need to achieve and get all the information you are after
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 2/20/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >All that is necessary to have a group of processes do something
> >in an unnamed fashion is to hang a pointer off of the task_struct.
> >That's easy.
>
> Right, adding a pointer to task_struct
On 2/20/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
I don't necessarily agree with the 'heirarchy' bit. It doesn't have to
be so segregated. But I think we already covered that in this thread.
OK, but it's much easier to use a hierarchical system as a flat system
(just don't create children)
Paul Menage wrote:
>> No. A reverse mapping is not needed and is not interesting.
>>
> ... to you.
>
You're missing the point of Eric's next sentence. If you can achieve
everything you need to achieve and get all the information you are after
without it, then it is uninteresting.
>> As
Paul Menage wrote:
>> The term "segregated group of processes" is too vague. Segregated for
>> what? What is the kernel supposed to do with this information?
>>
> The generic part of the kernel just keeps track of the fact that
> they're segregated (and their children, etc).
>
> It's the
On 2/20/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Sam said "the NSProxy *is* the container". You appear to be planning
> to have some namespaces, possibly not aggregated within the nsproxy
> (pid namespace?) but are you planning to have some higher-level
> "container" object that
On 2/20/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
The term "segregated group of processes" is too vague. Segregated for
what? What is the kernel supposed to do with this information?
The generic part of the kernel just keeps track of the fact that
they're segregated (and their children,
Paul Menage wrote:
>> Using the container name is bad and it led to this stupid argument.
>>
>> The fundamental unit of what we have merged into the kernel is the
>> namespace. The aggregate of all namespaces and everything is the
>> container.
>>
> What are you defining here as
"Paul Menage" <[EMAIL PROTECTED]> writes:
> What are you defining here as "everything"? If you mean "all things
> that could be applied to a segregated group of processes such as a
> virtual server", then "container" seems like a good name for my
> patches, since it allows you to aggregate
On 2/20/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
>>
>> I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
>> We decided a long time ago that a container was basically just
"Paul Menage" <[EMAIL PROTECTED]> writes:
> On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
>>
>> I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
>> We decided a long time ago that a container was basically just a set of
>> namespaces, which includes all of the
Paul Menage [EMAIL PROTECTED] writes:
On 2/12/07, Sam Vilain [EMAIL PROTECTED] wrote:
I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
We decided a long time ago that a container was basically just a set of
namespaces, which includes all of the subsystems you mention.
On 2/20/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Paul Menage [EMAIL PROTECTED] writes:
On 2/12/07, Sam Vilain [EMAIL PROTECTED] wrote:
I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
We decided a long time ago that a container was basically just a set of
Paul Menage [EMAIL PROTECTED] writes:
What are you defining here as everything? If you mean all things
that could be applied to a segregated group of processes such as a
virtual server, then container seems like a good name for my
patches, since it allows you to aggregate namespaces, resource
Paul Menage wrote:
Using the container name is bad and it led to this stupid argument.
The fundamental unit of what we have merged into the kernel is the
namespace. The aggregate of all namespaces and everything is the
container.
What are you defining here as everything? If you mean
On 2/20/07, Sam Vilain [EMAIL PROTECTED] wrote:
The term segregated group of processes is too vague. Segregated for
what? What is the kernel supposed to do with this information?
The generic part of the kernel just keeps track of the fact that
they're segregated (and their children, etc).
On 2/20/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
Sam said the NSProxy *is* the container. You appear to be planning
to have some namespaces, possibly not aggregated within the nsproxy
(pid namespace?) but are you planning to have some higher-level
container object that aggregates the
Paul Menage wrote:
The term segregated group of processes is too vague. Segregated for
what? What is the kernel supposed to do with this information?
The generic part of the kernel just keeps track of the fact that
they're segregated (and their children, etc).
It's the clients of
Paul Menage wrote:
No. A reverse mapping is not needed and is not interesting.
... to you.
You're missing the point of Eric's next sentence. If you can achieve
everything you need to achieve and get all the information you are after
without it, then it is uninteresting.
As long as
On 2/20/07, Sam Vilain [EMAIL PROTECTED] wrote:
I don't necessarily agree with the 'heirarchy' bit. It doesn't have to
be so segregated. But I think we already covered that in this thread.
OK, but it's much easier to use a hierarchical system as a flat system
(just don't create children)
Quoting Paul Menage ([EMAIL PROTECTED]):
On 2/20/07, Eric W. Biederman [EMAIL PROTECTED] wrote:
All that is necessary to have a group of processes do something
in an unnamed fashion is to hang a pointer off of the task_struct.
That's easy.
Right, adding a pointer to task_struct is easy.
On 2/20/07, Sam Vilain [EMAIL PROTECTED] wrote:
Paul Menage wrote:
No. A reverse mapping is not needed and is not interesting.
... to you.
You're missing the point of Eric's next sentence. If you can achieve
everything you need to achieve and get all the information you are after
without
Quoting Sam Vilain ([EMAIL PROTECTED]):
Paul Menage wrote:
We talked about naming a bit before, see
http://lkml.org/lkml/2006/3/21/403 and possibly other threads. So,
anyway, feel free to flog this old dead horse and suggest different
terms. We've all had long enough to think about it
On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Not every module, you just make them on sensible, planned groupings.
The danger is that the "container" group becomes a fallback grouping for
things when people can't be bothered thinking about it properly, and
everything including the kitchen
Paul Menage wrote:
>> Ask yourself this - what do you need the container structure for so
>> badly, that virtualising the individual resources does not provide for?
>>
> Primarily, that otherwise every module that wants to affect/monitor
> behaviour of a group of associated processes has to
On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
Ask yourself this - what do you need the container structure for so
badly, that virtualising the individual resources does not provide for?
Primarily, that otherwise every module that wants to affect/monitor
behaviour of a group of associated
Paul Menage wrote:
>> I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
>> We decided a long time ago that a container was basically just a set of
>> namespaces, which includes all of the subsystems you mention.
>>
> You may have done that, but the CKRM/ResGroups
On 2/12/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
Well it's an unfortunate conflict, but I don't see where we have any
standing to make Paul change his terminology :)
I have no huge problem with changing my terminology in the interest of
wider adoption. "Container" seems like an
On 2/12/07, Sam Vilain <[EMAIL PROTECTED]> wrote:
I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
We decided a long time ago that a container was basically just a set of
namespaces, which includes all of the subsystems you mention.
You may have done that, but the
[EMAIL PROTECTED] wrote:
> Generic Process Containers
> --
>
> There have recently been various proposals floating around for
> resource management/accounting and other task grouping subsystems in
> the kernel, including ResGroups, User BeanCounters, NSProxy
> containers,
Quoting Sam Vilain ([EMAIL PROTECTED]):
> [EMAIL PROTECTED] wrote:
> > Generic Process Containers
> > --
> >
> > There have recently been various proposals floating around for
> > resource management/accounting and other task grouping subsystems in
> > the kernel, including
Paul M, responding to Paul J:
> I think it could be made smarter than that, e.g. have a workqueue task
> that's only woken when a refcount does actually reach zero. (I think
> that waking a workqueue task is something that can be done without too
> much worry about locks)
>
> >
> > Can you
On 2/12/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
You'll have a rough time selling me on the idea that some kernel thread
should be waking up every few seconds, grabbing system-wide locks, on a
big honkin NUMA box, for the few times per hour, or less, that a cpuset is
abandoned.
I think it
> - temporarily removed the "release agent" support.
ouch
> ... it can be re-added ... via a kernel thread that periodically polls
> containers ...
double ouch.
You'll have a rough time selling me on the idea that some kernel thread
should be waking up every few seconds, grabbing system-wide
--
This is an update to my multi-hierarchy multi-subsystem generic
process containers patch. Changes since V6 (22nd December) include:
- updated to 2.6.20
- added more details about multiple hierarchy support in the
documentation
- reduced the per-task memory overhead to one pointer
--
This is an update to my multi-hierarchy multi-subsystem generic
process containers patch. Changes since V6 (22nd December) include:
- updated to 2.6.20
- added more details about multiple hierarchy support in the
documentation
- reduced the per-task memory overhead to one pointer
- temporarily removed the release agent support.
ouch
... it can be re-added ... via a kernel thread that periodically polls
containers ...
double ouch.
You'll have a rough time selling me on the idea that some kernel thread
should be waking up every few seconds, grabbing system-wide
On 2/12/07, Paul Jackson [EMAIL PROTECTED] wrote:
You'll have a rough time selling me on the idea that some kernel thread
should be waking up every few seconds, grabbing system-wide locks, on a
big honkin NUMA box, for the few times per hour, or less, that a cpuset is
abandoned.
I think it
Paul M, responding to Paul J:
I think it could be made smarter than that, e.g. have a workqueue task
that's only woken when a refcount does actually reach zero. (I think
that waking a workqueue task is something that can be done without too
much worry about locks)
Can you explain to me
Quoting Sam Vilain ([EMAIL PROTECTED]):
[EMAIL PROTECTED] wrote:
Generic Process Containers
--
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups,
[EMAIL PROTECTED] wrote:
Generic Process Containers
--
There have recently been various proposals floating around for
resource management/accounting and other task grouping subsystems in
the kernel, including ResGroups, User BeanCounters, NSProxy
containers, and
On 2/12/07, Sam Vilain [EMAIL PROTECTED] wrote:
I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
We decided a long time ago that a container was basically just a set of
namespaces, which includes all of the subsystems you mention.
You may have done that, but the
On 2/12/07, Serge E. Hallyn [EMAIL PROTECTED] wrote:
Well it's an unfortunate conflict, but I don't see where we have any
standing to make Paul change his terminology :)
I have no huge problem with changing my terminology in the interest of
wider adoption. Container seems like an appropriate
Paul Menage wrote:
I know I'm a bit out of touch, but AIUI the NSProxy *is* the container.
We decided a long time ago that a container was basically just a set of
namespaces, which includes all of the subsystems you mention.
You may have done that, but the CKRM/ResGroups independently
On 2/12/07, Sam Vilain [EMAIL PROTECTED] wrote:
Ask yourself this - what do you need the container structure for so
badly, that virtualising the individual resources does not provide for?
Primarily, that otherwise every module that wants to affect/monitor
behaviour of a group of associated
Paul Menage wrote:
Ask yourself this - what do you need the container structure for so
badly, that virtualising the individual resources does not provide for?
Primarily, that otherwise every module that wants to affect/monitor
behaviour of a group of associated processes has to implement
On 2/12/07, Sam Vilain [EMAIL PROTECTED] wrote:
Not every module, you just make them on sensible, planned groupings.
The danger is that the container group becomes a fallback grouping for
things when people can't be bothered thinking about it properly, and
everything including the kitchen sink
48 matches
Mail list logo
