On Thu, Jun 28, 2007 at 05:27:25PM -0400, Paul Menage wrote:
> So maybe this would be better handled in userspace? Have a daemon
> listing on a process connector socket, and move processes between
> containers based on notifications from the connector and user-defined
> rules.
>
> We'd probably al
On 5/30/07, William Lee Irwin III <[EMAIL PROTECTED]> wrote:
On Wed, May 30, 2007 at 12:14:55AM -0700, Andrew Morton wrote:
> So how do we do this?
> Is there any sneaky way in which we can modify the kernel so that this new
> code gets exercised more? Obviously, tossing init into some default
>
Serge wrote:
> Paul (Jackson), is this comment added in cpusets close enough to what
> you were asking for?
This comment?
+ * Currently we refuse to set up the container - thereby
+ * refusing the task to be entered, and as a result refusing
+ * the sys_unshare() or clone() which initiated it - i
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 6/8/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >
> >I do fear that that could become a maintenance nightmare. For instance
> >right now there's the call to fsnotify_mkdir(). Other such hooks might
> >be placed at vfs_mkdir, which we'd then likel
On 6/8/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
I do fear that that could become a maintenance nightmare. For instance
right now there's the call to fsnotify_mkdir(). Other such hooks might
be placed at vfs_mkdir, which we'd then likely want to have placed in
our container_mkdir() and co
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 6/8/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >
> >The problem is container_clone() doesn't call ->create explicitly, it
> >does vfs_mkdir. So we have no real way of passing in clone_task.
> >
>
> Good point.
>
> Looking at vfs_mkdir(), it's p
> Anyway the patch I sent is simple enough, and if users end up demanding
> the ability to better deal with exclusive cpusets, the patch will be
> simple enough to extend by changing cpuset_auto_setup(), so let's
> stick with that patch since it's your preference (IIUC).
Yeah - probably so.
W
On 6/8/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
The problem is container_clone() doesn't call ->create explicitly, it
does vfs_mkdir. So we have no real way of passing in clone_task.
Good point.
Looking at vfs_mkdir(), it's pretty simple, and really the only bits
that apply to contain
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 6/8/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >
> >Anyway the patch I sent is simple enough, and if users end up demanding
> >the ability to better deal with exclusive cpusets, the patch will be
> >simple enough to extend by changing cpuset_auto_
On 6/8/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
Anyway the patch I sent is simple enough, and if users end up demanding
the ability to better deal with exclusive cpusets, the patch will be
simple enough to extend by changing cpuset_auto_setup(), so let's
stick with that patch since it's yo
Quoting Paul Jackson ([EMAIL PROTECTED]):
> > > The set of people using exclusive cpusets is roughly some subset of
> > > those running multiple, cpuset isolated, non-cooperating jobs on big
> > > iron, usually with the aid of a batch scheduler.
> >
> > Unfortunately I would imagine these users to
> > The set of people using exclusive cpusets is roughly some subset of
> > those running multiple, cpuset isolated, non-cooperating jobs on big
> > iron, usually with the aid of a batch scheduler.
>
> Unfortunately I would imagine these users to be very intereseted in
> providing checkpoint/resta
Quoting Paul Jackson ([EMAIL PROTECTED]):
> > For /cpusets/set0/set1 to have cpu 1 exclusively, does /cpusets/set0
> > also have to have it exclusively?
>
> Yes.
>
> > If so, then clearly this approach won't work, since if any container has
> > exclusive cpus, then every container will have sibli
> For /cpusets/set0/set1 to have cpu 1 exclusively, does /cpusets/set0
> also have to have it exclusively?
Yes.
> If so, then clearly this approach won't work, since if any container has
> exclusive cpus, then every container will have siblings with exclusive
> cpus, and unshare still isn't possi
Quoting Paul Jackson ([EMAIL PROTECTED]):
> > I suppose as a cleaner alternative we could
> > add a container_subsys->inherit_defaults() handler, to be called at
> > container_clone(), and for cpusets this would set cpus and mems to
> > the parent values - sibling exclusive values. If that comes
> I suppose as a cleaner alternative we could
> add a container_subsys->inherit_defaults() handler, to be called at
> container_clone(), and for cpusets this would set cpus and mems to
> the parent values - sibling exclusive values. If that comes to nothing,
> then the attach_task() is still refu
Quoting Paul Jackson ([EMAIL PROTECTED]):
> > > I wasn't paying close enough attention to understand why you couldn't
> > > do it in two steps - make the container, and then populate it with
> > > resources.
> >
> > Sorry, please clarify - are you saying that now you do understand, or
> > that I s
> > I wasn't paying close enough attention to understand why you couldn't
> > do it in two steps - make the container, and then populate it with
> > resources.
>
> Sorry, please clarify - are you saying that now you do understand, or
> that I should explain?
Could you explain -- I still don't und
Quoting Paul Jackson ([EMAIL PROTECTED]):
> > Would it then make sense to just
> > default to (parent_set - sibling_exclusive_set) for a new sibling's
> > value?
>
> Which could well be empty, which in turn puts one back in the position
> of dealing with a newborn cpuset that is empty (of cpus or
Serge wrote:
> Odd, I thought rm -rf used to work in the past,
> but i'm likely wrong.
I'm pretty sure it never worked.
And I've probably tested it myself, every few months,
since the birth of cpusets, when I forget and type it
again, and then stare dumbly at the screen wondering
what all the com
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 6/4/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >[EMAIL PROTECTED] root]# rm -rf /containers/1
>
> Just use "rmdir /containers/1" here.
Hmm. Ok, that works... Odd, I thought rm -rf used to work in the past,
but i'm likely wrong.
thanks,
-serge
> [EMAIL PROTECTED] root]# rm -rf /containers/1
No - not 'rm -fr'.
'rmdir'
Remove the cpuset directory, not start bottom up
trying to remove the files first.
The poor 'rm -fr' command doesn't understand the
rather odd nature of cpuset file systems, which
have all files coming and going automag
> Would it then make sense to just
> default to (parent_set - sibling_exclusive_set) for a new sibling's
> value?
Which could well be empty, which in turn puts one back in the position
of dealing with a newborn cpuset that is empty (of cpus or of memory),
or else it introduces a new and odd constr
On 6/4/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
[EMAIL PROTECTED] root]# rm -rf /containers/1
Just use "rmdir /containers/1" here.
Ah, I see the second time I typed 'ls /containers/1/tasks' instead of
cat. When I then used cat, the file was empty, and I got an oops just
like Pavel rep
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 6/4/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
> >
> >2. I can't delete containers because of the files they contain, and
> >am not allowed to delete those files by hand.
> >
>
> You should be able to delete a container with rmdir as long as it's
>
Quoting Paul Menage ([EMAIL PROTECTED]):
> On 6/4/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> >
> >Yup - early in the life of cpusets, a created cpuset inherited the cpus
> >and mems of its parent. But that broke the exclusive property big
> >time. You will recall that a cpu_exclusive or mem_ex
Paul M wrote:
> Maybe we could make it a per-cpuset option whether children should
> inherit mems/cpus or not?
I suppose, if those needing inherited mems/cpus need it bad enough.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
On 6/4/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote:
2. I can't delete containers because of the files they contain, and
am not allowed to delete those files by hand.
You should be able to delete a container with rmdir as long as it's
not in use - its control files will get cleaned up automa
On 6/4/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
Yup - early in the life of cpusets, a created cpuset inherited the cpus
and mems of its parent. But that broke the exclusive property big
time. You will recall that a cpu_exclusive or mem_exclusive cpuset
cannot overlap the cpus or memory, res
What you describe, Serge, sounds like semantics carried over from cpusets.
Serge wrote:
> A task can't join a cpuset unless 'cpus' and 'mems' are set.
Yup - don't want to run a task in a cpuset that lacks cpu, or lacks
memory. Hard to run without those.
> These don't seem to automatically inher
Hi Paul,
I've got two problems working with this patchset:
1. A task can't join a cpuset unless 'cpus' and 'mems' are set. These
don't seem to automatically inherit the parent's values. So when I do
mount -t container -o ns,cpuset nsproxy /containers
(unshare a namespace)
the
Hi Paul.
I have faced a warning during testing your patches.
The testcase is simple:
# ssh to the node
mount -t container none /cnt/rss/ -o rss
mkdir /cnt/rss/0
/bin/echo $$ > /cnt/rss/0/tasks
# exit with ^d and ssh again
rmdir /cnt/rss/0
dmesg
BUG: at mm/slab.c:777 __find_ge
Pavel Emelianov wrote:
>>> Is there any sneaky way in which we can modify the kernel so that this new
>>> code gets exercised more? Obviously, tossing init into some default
>>> system-wide container would be a start. But I wonder if we can be
>>> sneakier - for example, create a new container on
Balbir Singh wrote:
> Andrew Morton wrote:
>> On Tue, 29 May 2007 06:01:04 -0700 [EMAIL PROTECTED] wrote:
>>
>>> This is an update to my multi-hierarchy multi-subsystem generic
>>> process containers patch.
>>>
>>> ...
>>>
>>> Still TODO:
>>>
>>> ...
>>>
>>> - lots more testing
>>>
>> So how do we
Andrew Morton wrote:
> On Tue, 29 May 2007 06:01:04 -0700 [EMAIL PROTECTED] wrote:
>
>> This is an update to my multi-hierarchy multi-subsystem generic
>> process containers patch.
>>
>> ...
>>
>> Still TODO:
>>
>> ...
>>
>> - lots more testing
>>
>
> So how do we do this?
>
> Is there any sneak
On Wed, May 30, 2007 at 12:14:55AM -0700, Andrew Morton wrote:
> So how do we do this?
> Is there any sneaky way in which we can modify the kernel so that this new
> code gets exercised more? Obviously, tossing init into some default
> system-wide container would be a start. But I wonder if we ca
On Tue, 29 May 2007 06:01:04 -0700 [EMAIL PROTECTED] wrote:
> This is an update to my multi-hierarchy multi-subsystem generic
> process containers patch.
>
> ...
>
> Still TODO:
>
> ...
>
> - lots more testing
>
So how do we do this?
Is there any sneaky way in which we can modify the kernel
This is an update to my multi-hierarchy multi-subsystem generic
process containers patch. Changes since V9 (April 27th) include:
- The patchset has been rebased over 2.6.22-rc2-mm1
- A lattice of lists linking tasks to their css_groups and css_groups
to their containers has been added to support
38 matches
Mail list logo
