[EMAIL PROTECTED] wrote:
> Pavel Emelianov [EMAIL PROTECTED] wrote:
> | When user send signal from (say) init namespace to any task in a sub
> | namespace the siginfo struct must not carry the sender's pid value, as
> | this value may refer to some task in the destination namespace and thus
> | may
[EMAIL PROTECTED] wrote:
> Pavel Emelianov [EMAIL PROTECTED] wrote:
> | When showing pid to user or getting the pid numerical id for in-kernel
> | use the value of this id may differ depending on the namespace.
> |
> | This set of helpers is used to get the global pid nr, the virtual (i.e.
> | see
Cedric Le Goater wrote:
> Pavel Emelianov wrote:
>> The set of functions process_session, task_session, process_group
>> and task_pgrp is confusing, as the names can be mixed with each other
>> when looking at the code for a long time.
>>
>> The proposals are to
>> * equip the functions that return
[EMAIL PROTECTED] wrote:
> Pavel Emelianov [EMAIL PROTECTED] wrote:
> | When searching the task by numerical id on may need to find
> | it using global pid (as it is done now in kernel) or by its
> | virtual id, e.g. when sending a signal to a task from one
> | namespace the sender will specify the
Cedric Le Goater wrote:
> Pavel Emelianov wrote:
>> The most importaint change is moving exit_task_namespaces()
>> inside exit_notify() to makes it possible to notify the
>> exiting task's parent. However this should be done before
>> release_task() to address the issue pointed by Sukadev with
>> N
On 7/9/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
> - splitting the memory and cpu isolation parts of cpusets into two
> separate subsystems (still backwards-compatible)
I see memory isolation using cpusets as very topology dependent
and I am not sure if the model would work for memory controll
Paul Menage wrote:
[snip]
> Some possible subsystems that I'm thinking of include:
>
> - splitting the memory and cpu isolation parts of cpusets into two
> separate subsystems (still backwards-compatible)
I see memory isolation using cpusets as very topology dependent
and I am not sure if the mo
On 7/2/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
4. task containers functionality
How about if we adopt "process containers" or "task containers" as the
term for the generic container framework, to distinguish from more
general user-space containers? In the same way that "task_struc
Pavel Emelianov [EMAIL PROTECTED] wrote:
| When showing pid to user or getting the pid numerical id for in-kernel
| use the value of this id may differ depending on the namespace.
|
| This set of helpers is used to get the global pid nr, the virtual (i.e.
| seen by task in its namespace) nr and th
Peter Zijlstra wrote:
> On Sun, 2028-02-27 at 02:39 -0500, Balbir Singh wrote:
>
>> I am not a CLUI expert, but rounding off bytes will something that
>> the administrators will probably complain about. Since we manage
>> the controller memory in pages, it might be the easiest unit to use.
>> The
Cedric Le Goater [EMAIL PROTECTED] wrote:
| Pavel Emelianov wrote:
| > struct pid_namespace will have the kmem_cache to allocate
| > the pids from, the parent, as they are hierarchical, and
| > the level of nesting value.
| >
| > struct pid will have a variable length array of pid_number-s
| > one
I am not able to find a specific patch that this might be in,
but what happens when the child-reaper of a container exits ?
Do you terminate all processes in the container ? I thought
that was discussed earlier and the consensus was to terminate
all processes in that container and its subordinate c
Pavel Emelianov [EMAIL PROTECTED] wrote:
| When user send signal from (say) init namespace to any task in a sub
| namespace the siginfo struct must not carry the sender's pid value, as
| this value may refer to some task in the destination namespace and thus
| may confuse the application.
Also, do
Pavel Emelianov [EMAIL PROTECTED] wrote:
| When searching the task by numerical id on may need to find
| it using global pid (as it is done now in kernel) or by its
| virtual id, e.g. when sending a signal to a task from one
| namespace the sender will specify the task's virtual id.
|
| Signed-off
Pavel Emelianov [EMAIL PROTECTED] wrote:
| This is "submition for inclusion" of hierarchical, not kconfig
| configurable, zero overheaded ;) pid namespaces.
|
| The overall idea is the following:
|
| The namespace are organized as a tree - once a task is cloned
| with CLONE_NEWPIDS (yes, I've als
On Mon, 2007-07-09 at 22:06 +0200, Cedric Le Goater wrote:
> Badari Pulavarty wrote:
> > On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote:
> >> This is "submition for inclusion" of hierarchical, not kconfig
> >> configurable, zero overheaded ;) pid namespaces.
> >
> > Not able to boot my p
Pavel Emelianov [EMAIL PROTECTED] wrote:
| This is "submition for inclusion" of hierarchical, not kconfig
| configurable, zero overheaded ;) pid namespaces.
|
| The overall idea is the following:
|
| The namespace are organized as a tree - once a task is cloned
| with CLONE_NEWPIDS (yes, I've al
Pavel Emelianov wrote:
> struct pid_namespace will have the kmem_cache to allocate
> the pids from, the parent, as they are hierarchical, and
> the level of nesting value.
>
> struct pid will have a variable length array of pid_number-s
> one for each namespace this pid lives in. The level value
>
Pavel Emelianov wrote:
> The most importaint change is moving exit_task_namespaces()
> inside exit_notify() to makes it possible to notify the
> exiting task's parent. However this should be done before
> release_task() to address the issue pointed by Sukadev with
> NFS kernel thread.
Have you act
Pavel Emelianov wrote:
> The set of functions process_session, task_session, process_group
> and task_pgrp is confusing, as the names can be mixed with each other
> when looking at the code for a long time.
>
> The proposals are to
> * equip the functions that return the integer with _nr suffix to
3. Suka assumes that pid namespace can live without proc mount
and tries to make the code work with pid_ns->proc_mnt change
from NULL to not-NULL from times to times.
My code calls the kern_mount() at the namespace creation and
thus the pid_namespace always work
Badari Pulavarty wrote:
> On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote:
>> This is "submition for inclusion" of hierarchical, not kconfig
>> configurable, zero overheaded ;) pid namespaces.
>
> Not able to boot my ppc64 machine with the patchset :(
I can't boot either on a x86_64 but
On Mon, 2007-07-09 at 09:58 +0400, Pavel Emelianov wrote:
> Dave Hansen wrote:
> > On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote:
> >> This is "submition for inclusion" of hierarchical, not kconfig
> >> configurable, zero overheaded ;) pid namespaces.
> >
> > Pavel, I'm a bit disappoint
On Mon, 2007-07-09 at 11:16 +0400, Pavel Emelianov wrote:
> Dave Hansen wrote:
> > On Thu, 2007-07-05 at 22:20 -0700, Balbir Singh wrote:
> >> +/*
> >> + * the core object. the container that wishes to account for some
> >> + * resource may include this counter into its structures and use
> >> + *
On Mon, Jul 09, 2007 at 05:16:17PM +0400, Pavel Emelianov wrote:
> Herbert Poetzl wrote:
> > On Fri, Jul 06, 2007 at 12:01:59PM +0400, Pavel Emelianov wrote:
> >> This is "submition for inclusion" of hierarchical, not kconfig
> >> configurable, zero overheaded ;) pid namespaces.
> >>
> >> The overa
On Fri, 2007-07-06 at 12:01 +0400, Pavel Emelianov wrote:
> This is "submition for inclusion" of hierarchical, not kconfig
> configurable, zero overheaded ;) pid namespaces.
Not able to boot my ppc64 machine with the patchset :(
Thanks,
Badari
Unable to handle kernel paging request for data at a
Between the "normal" case and the "net namespace + macvlan" case,
results are about the same for both the throughput and the local CPU
load for the following test types: TCP_MAERTS, TCP_RR, UDP_STREAM, UDP_RR.
macvlan looks like a very good candidate for network namespace in these
cases.
Bu
Quoting Paul Jackson ([EMAIL PROTECTED]):
> Serge wrote:
> > So if any development is planned over the next year on top of
> > Pauls Menage's containers and/or cpusets, we'd like that listed
> > here as well.
>
> Well, apparenntly you guys are planning some "container" stuff
> that is on top of or
Paul Jackson wrote:
> Serge wrote:
>
>>So if any development is planned over the next year on top of
>>Pauls Menage's containers and/or cpusets, we'd like that listed
>>here as well.
>
>
> Well, apparenntly you guys are planning some "container" stuff
> that is on top of or relates to in some wa
Quoting Paul Jackson ([EMAIL PROTECTED]):
> Thanks for responding, Eric.
>
> For those like me (I suspect I'm not alone) who drift in and out of
> this discussion, perhaps this would be a good time to describe again
> what are the containers you're discussing here - their key purpose(s)
> and thei
Serge wrote:
> So if any development is planned over the next year on top of
> Pauls Menage's containers and/or cpusets, we'd like that listed
> here as well.
Well, apparenntly you guys are planning some "container" stuff
that is on top of or relates to in some way unclear to me with
Menage's cont
Quoting Paul Jackson ([EMAIL PROTECTED]):
> > they are indirectly related. Sorry for the noise.
>
> Well ... if this is noise, it should be me apologizing, not you .
> I'm the one who asked.
>
> > Paul Menage's container patches provide a process aggregation mechanism,
> > like PAGG did. This is
Jan Kara wrote:
> Hello,
>
> On Mon 02-07-07 18:16:09, Kirill Korotaev wrote:
>
>>it looks like the following fix:
>>http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=43c3e6f5abdf6acac9b90c86bf03f995bf7d3d92
>>
>>was lost after resurrecting of the spliced checkpoin
Herbert Poetzl wrote:
> On Fri, Jul 06, 2007 at 12:01:59PM +0400, Pavel Emelianov wrote:
>> This is "submition for inclusion" of hierarchical, not kconfig
>> configurable, zero overheaded ;) pid namespaces.
>>
>> The overall idea is the following:
>>
>> The namespace are organized as a tree - once
"Denis V. Lunev" <[EMAIL PROTECTED]> writes:
> With a small thing, though.
>
> We have agreed that we should submit infrastructure pieces one by one,
> like daniel propose. These pieces are common for all approaches and they
> will increase the probability of the inclusion of the main piece. We
>
On Thu, Jul 05, 2007 at 04:19:08PM +0200, Cedric Le Goater wrote:
> Serge E. Hallyn wrote:
> > We are trying to create a roadmap for the next year of
> > 'container' development, to be reported to the upcoming kernel
> > summit. Containers here is a bit of an ambiguous term, so we are
> > taking i
On Mon, Jul 02, 2007 at 11:55:04AM -0500, Serge E. Hallyn wrote:
> We are trying to create a roadmap for the next year of
> 'container' development, to be reported to the upcoming kernel
> summit. Containers here is a bit of an ambiguous term, so we are
> taking it to mean all of:
>
> 1. na
On Fri, Jul 06, 2007 at 12:01:59PM +0400, Pavel Emelianov wrote:
> This is "submition for inclusion" of hierarchical, not kconfig
> configurable, zero overheaded ;) pid namespaces.
>
> The overall idea is the following:
>
> The namespace are organized as a tree - once a task is cloned
> with CLON
On Fri, Jul 06, 2007 at 06:48:15PM +0200, Benjamin Thery wrote:
> Following a discussion we had at OLS concerning L2 network namespace
> performances and how the new macvlan driver could potentially improve
> them, I've ported the macvlan patchset on top of Eric's net namespace
> patchset on 2.6.22
On Sun, 2028-02-27 at 02:39 -0500, Balbir Singh wrote:
> I am not a CLUI expert, but rounding off bytes will something that
> the administrators will probably complain about. Since we manage
> the controller memory in pages, it might be the easiest unit to use.
> The output is totally different ma
Dave Hansen wrote:
> On Thu, 2007-07-05 at 22:20 -0700, Balbir Singh wrote:
>> +/*
>> + * the core object. the container that wishes to account for some
>> + * resource may include this counter into its structures and use
>> + * the helpers described beyond
>> + */
>
> I'm going to nitpick a bit h
41 matches
Mail list logo
