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
>
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
> 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
21 matches
Mail list logo
