KAMEZAWA Hiroyuki wrote:
> Hi, thank you for review.
>
Your always welcome, thanks for helping with the controller.
> On Mon, 01 Oct 2007 09:46:02 +0530
> Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>>> @@ -424,17 +424,80 @@ void mem_cgroup_uncharge(struct page_cgr
>>> if (atomic_dec_and_test
Hi, thank you for review.
On Mon, 01 Oct 2007 09:46:02 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> > @@ -424,17 +424,80 @@ void mem_cgroup_uncharge(struct page_cgr
> > if (atomic_dec_and_test(&pc->ref_cnt)) {
> > page = pc->page;
> > lock_page_cgroup(page);
> > -
KAMEZAWA Hiroyuki wrote:
> An experimental patch.
>
> This patch adds an interface to uncharge all pages in memory cgroup if
> no tasks are in it. By this, a user can remove cgroup by 'rmdir'.
>
> To uncharge all remaing pages in cgrop, echo -n 0 to memory.control_type.
> (Just for test, please a
Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>
>>Maybe I can save you some time: we used to do down_trylock()
>>for the rtnl mutex, so senders would simply return if someone
>>else was already processing the queue *or* the rtnl was locked
>>for some other reason. In th
Hmm, so it looks like we do not need this queue processing at all...
Regards,
Den
Eric W. Biederman wrote:
> Patrick McHardy <[EMAIL PROTECTED]> writes:
>
>> Maybe I can save you some time: we used to do down_trylock()
>> for the rtnl mutex, so senders would simply return if someone
>> e
Andrew wrote:
> so when
> their bisection cursor moves within or after the cgroups patches, they'll
> still have CONFIG_CGROUPS=n. Serendipity.
Unless it's one of the configs that enables cgroups by default, thanks
to the patch:
task-containers-enable-containers-by-default-in-some-configs.patc
On Sun, 30 Sep 2007 02:15:36 -0700 Paul Jackson <[EMAIL PROTECTED]> wrote:
> Andrew wrote:
> > And I think that's OK, because we don't care about git bisectability with
> > CONFIG_CGROUPS=y (I think?) Anyone who is bisecting through the middle of
> > the containers patch series is not searching fo
Andrew wrote:
> And I think that's OK, because we don't care about git bisectability with
> CONFIG_CGROUPS=y (I think?) Anyone who is bisecting through the middle of
> the containers patch series is not searching for a containers problem, so
> they can just configure it all off.
Ok - I guess.
In
On Sun, 30 Sep 2007 00:10:18 -0700 "Paul Menage" <[EMAIL PROTECTED]> wrote:
> On 9/29/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> > Paul M:
> >
> > This patch doesn't build for me in the following case. If I apply the
> > rest of the containersv11 patches, it builds, but if I happen to bisect
>
> fixing this is on my todo list.
thanks!
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
___
Containers mailing list
[EMAIL PROT
On 9/29/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> There are some 21 mentions of 'manage_mutex' in the comments of
> kernel/cpuset.c remaining after this patch is applied, but no such
> mutex exists anymore.
>
Oops, sorry - fixing this is on my todo list.
Paul
_
On 9/29/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Paul M:
>
> This patch doesn't build for me in the following case. If I apply the
> rest of the containersv11 patches, it builds, but if I happen to bisect
> into this set of patches having applied only:
These patches weren't the normal style
12 matches
Mail list logo
