Michal Hocko | 16 Nov 22:50 2011
Picon

[PATCH] cgroup_freezer: fix freezing groups with stopped tasks

2d3cbf8b (cgroup_freezer: update_freezer_state() does incorrect state
transitions) removed is_task_frozen_enough and replaced it with a simple
frozen call. This, however, breaks freezing for a group with stopped tasks
because those cannot be frozen and so the group remains in CGROUP_FREEZING
state (update_if_frozen doesn't count stopped tasks) and never reaches
CGROUP_FROZEN.

Let's add is_task_frozen_enough back and use it at the original locations
(update_if_frozen and try_to_freeze_cgroup). Semantically we consider
stopped tasks as frozen enough so we should consider both cases when
testing frozen tasks.

Testcase:
mkdir /dev/freezer
mount -t cgroup -o freezer none /dev/freezer
mkdir /dev/freezer/foo
sleep 1h &
pid=$!
kill -STOP $pid
echo $pid > /dev/freezer/foo/tasks
echo FROZEN > /dev/freezer/foo/freezer.state
while true
do
        cat /dev/freezer/foo/freezer.state
        [ "`cat /dev/freezer/foo/freezer.state`" = "FROZEN" ] && break
        sleep 1
done
echo OK

Signed-off-by: Michal Hocko <mhocko@...>
(Continue reading)

KAMEZAWA Hiroyuki | 17 Nov 02:33 2011

[PATCH] fix mem_cgroup_split_huge_fixup to work efficiently.


I'll send this again when mm is shipped.
I sometimes see mem_cgroup_split_huge_fixup() in perf report and noticed
it's very slow. This fixes it. Any comments are welcome.

==
Subject: [PATCH] fix mem_cgroup_split_huge_fixup to work efficiently.

at split_huge_page(), mem_cgroup_split_huge_fixup() is called to
handle page_cgroup modifcations. It takes move_lock_page_cgroup()
and modify page_cgroup and LRU accounting jobs and called
HPAGE_PMD_SIZE - 1 times.

But thinking again,
  - compound_lock() is held at move_accout...then, it's not necessary
    to take move_lock_page_cgroup().
  - LRU is locked and all tail pages will go into the same LRU as
    head is now on.
  - page_cgroup is contiguous in huge page range.

This patch fixes mem_cgroup_split_huge_fixup() as to be called once per
hugepage and reduce costs for spliting.

Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...>
---
 include/linux/memcontrol.h |    5 ++---
 mm/huge_memory.c           |    3 ++-
 mm/memcontrol.c            |   32 ++++++++++++++++----------------
 3 files changed, 20 insertions(+), 20 deletions(-)

(Continue reading)

Balbir Singh | 17 Nov 08:12 2011
Picon

Re: [PATCH 4/4] provide a version of cpuacct statistics inside cpu cgroup

On Tue, Nov 15, 2011 at 9:29 PM, Glauber Costa <glommer@...> wrote:
> For users interested in using the information currently displayed
> at cpuacct.stat, we provide it inside the cpu cgroup.

I presume I need to mount cpu to see these stats and cpu implies
control today - no? Can I only monitor statistics without implementing
control? Please see the other thread as well.

Balbir
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Tomasz Buchert | 17 Nov 11:14 2011
Picon
Picon

Re: [PATCH] cgroup_freezer: fix freezing groups with stopped tasks

Hi,
I'm trying to understand now why I did that change in

2d3cbf8bc (the bug itself was in the if-the-else clause in 
update_if_frozen , anyway).
Well, when I look at this now I think that there is nothing wrong with 
your patch.
You can try my testcases from 2d3cbf8bc and 0bdba580, but it should be ok.

One thing I am not sure completely of is the following situation. So the 
group is frozen
with the STOPPED task inside. There are few questions:
* if you send SIGCONT to the task now, will it wake up?
* if yes - will it get *immediately* frozen?
I im going to check it myself, but maybe you can answer faster :).

Tomek

Le 16/11/2011 22:50, Michal Hocko a écrit :
> 2d3cbf8b (cgroup_freezer: update_freezer_state() does incorrect state
> transitions) removed is_task_frozen_enough and replaced it with a simple
> frozen call. This, however, breaks freezing for a group with stopped tasks
> because those cannot be frozen and so the group remains in CGROUP_FREEZING
> state (update_if_frozen doesn't count stopped tasks) and never reaches
> CGROUP_FROZEN.
>
> Let's add is_task_frozen_enough back and use it at the original locations
> (update_if_frozen and try_to_freeze_cgroup). Semantically we consider
> stopped tasks as frozen enough so we should consider both cases when
> testing frozen tasks.
(Continue reading)

Michal Hocko | 17 Nov 17:13 2011
Picon

Re: [PATCH] cgroup_freezer: fix freezing groups with stopped tasks

On Thu 17-11-11 11:14:53, Tomasz Buchert wrote:
> Hi,
> I'm trying to understand now why I did that change in
> 
> 2d3cbf8bc (the bug itself was in the if-the-else clause in
> update_if_frozen , anyway).
> Well, when I look at this now I think that there is nothing wrong
> with your patch.
> You can try my testcases from 2d3cbf8bc and 0bdba580, but it should be ok.

Yes, I have tried it before sending the patch.

> One thing I am not sure completely of is the following situation. So
> the group is frozen
> with the STOPPED task inside. There are few questions:
> * if you send SIGCONT to the task now, will it wake up?

No, it will enter refrigerator and wake up on thawing the group. Check
out `goto relock' after do_signal_stop returns.

--

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@...
(Continue reading)

Tomasz Buchert | 17 Nov 18:03 2011
Picon
Picon

Re: [PATCH] cgroup_freezer: fix freezing groups with stopped tasks

Le 17/11/2011 17:13, Michal Hocko a écrit :
> On Thu 17-11-11 11:14:53, Tomasz Buchert wrote:
>> Hi,
>> I'm trying to understand now why I did that change in
>>
>> 2d3cbf8bc (the bug itself was in the if-the-else clause in
>> update_if_frozen , anyway).
>> Well, when I look at this now I think that there is nothing wrong
>> with your patch.
>> You can try my testcases from 2d3cbf8bc and 0bdba580, but it should be ok.
> Yes, I have tried it before sending the patch.
>
>> One thing I am not sure completely of is the following situation. So
>> the group is frozen
>> with the STOPPED task inside. There are few questions:
>> * if you send SIGCONT to the task now, will it wake up?
> No, it will enter refrigerator and wake up on thawing the group. Check
> out `goto relock' after do_signal_stop returns.
>
I've checked your patch empirically few hours before :).
Also I've read get_signal_to_deliver() and you are right - it's gonna be 
fine.
The decision is not mine, of course, but I suggest to merge it.
Good work!

Tomek
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@...
More majordomo info at  http://vger.kernel.org/majordomo-info.html
(Continue reading)

Michal Hocko | 18 Nov 10:13 2011
Picon

Re: cgroup memory limit problems

Sorry to reply late

On Thu 10-11-11 09:10:12, KAMEZAWA Hiroyuki wrote:
> On Wed, 9 Nov 2011 23:58:57 +0100
[...]
> If you can, please try the latest kernels.
> 
> recent 2 commits
> 
> commit 79dfdaccd1d5b40ff7cf4a35a0e63696ebb78b4d
> " memcg: make oom_lock 0 and 1 based rather than counter "

This one needs a follow up fix (23751be0094012eb6b4756fa80ca54b3eb83069f
"memcg: fix hierarchical oom locking")

> commit 1d65f86db14806cf7b1218c7b4ecb8b4db5af27d
> "  mm: preallocate page before lock_page() at filemap COW"
> 
> are works well against fork-bomb under memcg. In my test, make -j under
> swapless memcg hangs (or takes long time) to be oom-killed.

--

-- 
Michal Hocko
SUSE Labs
SUSE LINUX s.r.o.
Lihovarska 1060/12
190 00 Praha 9    
Czech Republic
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
(Continue reading)

Michal Hocko | 18 Nov 17:35 2011
Picon

Re: [PATCH] fix mem_cgroup_split_huge_fixup to work efficiently.

On Thu 17-11-11 10:33:08, KAMEZAWA Hiroyuki wrote:
> 
> I'll send this again when mm is shipped.
> I sometimes see mem_cgroup_split_huge_fixup() in perf report and noticed
> it's very slow. This fixes it. Any comments are welcome.
> 
> ==
> Subject: [PATCH] fix mem_cgroup_split_huge_fixup to work efficiently.
> 
> at split_huge_page(), mem_cgroup_split_huge_fixup() is called to
> handle page_cgroup modifcations. It takes move_lock_page_cgroup()
> and modify page_cgroup and LRU accounting jobs and called
> HPAGE_PMD_SIZE - 1 times.
> 
> But thinking again,
>   - compound_lock() is held at move_accout...then, it's not necessary
>     to take move_lock_page_cgroup().
>   - LRU is locked and all tail pages will go into the same LRU as
>     head is now on.
>   - page_cgroup is contiguous in huge page range.
> 
> This patch fixes mem_cgroup_split_huge_fixup() as to be called once per
> hugepage and reduce costs for spliting.
> 
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...>

Yes, looks good. Andrew already took the patch, but just in case
Reviewed-by: Michal Hocko <mhocko@...>

Just one really minor comment bellow
(Continue reading)

Tejun Heo | 18 Nov 23:46 2011

[GIT PULL cgroup] Update maintainership

Hello, Linus.

Paul doesn't have enough time to maintain cgroup and we agreed that I
take over as one of the maintainers and maintain git tree.  I would be
doing standard for-next/fixes branch management.  At least until
things settle down, I wouldn't be committing any patch w/o Li Zefan's
co-ack.

At the moment, there are a few conflicting patchsets floating around
and sorting them out for the next merge window would be the first
priority.

Please pull from the following git branch to receive MAINTAINERS update.

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git for-3.2-fixes

Thank you.

Paul Menage (1):
      cgroup: Replace Paul Menage with Tejun Heo as cgroups maintainer

 MAINTAINERS |    3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f6bc29..78751bb 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
 <at>  <at>  -1927,10 +1927,11  <at>  <at>  S:	Maintained
 F:	drivers/connector/
(Continue reading)

Johannes Weiner | 21 Nov 11:42 2011

Re: [PATCH] fix mem_cgroup_split_huge_fixup to work efficiently.

On Thu, Nov 17, 2011 at 10:33:08AM +0900, KAMEZAWA Hiroyuki wrote:
> 
> I'll send this again when mm is shipped.
> I sometimes see mem_cgroup_split_huge_fixup() in perf report and noticed
> it's very slow. This fixes it. Any comments are welcome.
> 
> ==
> Subject: [PATCH] fix mem_cgroup_split_huge_fixup to work efficiently.
> 
> at split_huge_page(), mem_cgroup_split_huge_fixup() is called to
> handle page_cgroup modifcations. It takes move_lock_page_cgroup()
> and modify page_cgroup and LRU accounting jobs and called
> HPAGE_PMD_SIZE - 1 times.
> 
> But thinking again,
>   - compound_lock() is held at move_accout...then, it's not necessary
>     to take move_lock_page_cgroup().
>   - LRU is locked and all tail pages will go into the same LRU as
>     head is now on.
>   - page_cgroup is contiguous in huge page range.
> 
> This patch fixes mem_cgroup_split_huge_fixup() as to be called once per
> hugepage and reduce costs for spliting.
> 
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu <at> jp.fujitsu.com>

I agree with the changes, but since you are resending it anyway: I
think removing the move_lock and switching the hook to take care of
all tail pages in one go are two logical steps.  Would you mind
breaking it up into separate patches?
(Continue reading)


Gmane