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
wi
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
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) t
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 l
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 cli
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 aggrega
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)
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"?
"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 namespa
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
"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
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 si
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 im
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 pr
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 independ
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 appropri
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 CKRM/R
[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, an
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 explain
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 c
> - 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 l
--
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 (previous
24 matches
Mail list logo
