From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754901Ab3LPQmS (ORCPT ); Mon, 16 Dec 2013 11:42:18 -0500 Received: from zene.cmpxchg.org ([85.214.230.12]:50163 "EHLO zene.cmpxchg.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754565Ab3LPQmO (ORCPT ); Mon, 16 Dec 2013 11:42:14 -0500 Date: Mon, 16 Dec 2013 11:41:54 -0500 From: Johannes Weiner To: Michal Hocko Cc: Li Zefan , Hugh Dickins , Tejun Heo , Andrew Morton , KAMEZAWA Hiroyuki , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: 3.13-rc breaks MEMCG_SWAP Message-ID: <20131216164154.GX21724@cmpxchg.org> References: <52AEC989.4080509@huawei.com> <20131216095345.GB23582@dhcp22.suse.cz> <20131216104042.GC23582@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20131216104042.GC23582@dhcp22.suse.cz> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 16, 2013 at 11:40:42AM +0100, Michal Hocko wrote: > On Mon 16-12-13 10:53:45, Michal Hocko wrote: > > On Mon 16-12-13 17:36:09, Li Zefan wrote: > > > On 2013/12/16 16:36, Hugh Dickins wrote: > > > > CONFIG_MEMCG_SWAP is broken in 3.13-rc. Try something like this: > > > > > > > > mkdir -p /tmp/tmpfs /tmp/memcg > > > > mount -t tmpfs -o size=1G tmpfs /tmp/tmpfs > > > > mount -t cgroup -o memory memcg /tmp/memcg > > > > mkdir /tmp/memcg/old > > > > echo 512M >/tmp/memcg/old/memory.limit_in_bytes > > > > echo $$ >/tmp/memcg/old/tasks > > > > cp /dev/zero /tmp/tmpfs/zero 2>/dev/null > > > > echo $$ >/tmp/memcg/tasks > > > > rmdir /tmp/memcg/old > > > > sleep 1 # let rmdir work complete > > > > mkdir /tmp/memcg/new > > > > umount /tmp/tmpfs > > > > dmesg | grep WARNING > > > > rmdir /tmp/memcg/new > > > > umount /tmp/memcg > > > > > > > > Shows lots of WARNING: CPU: 1 PID: 1006 at kernel/res_counter.c:91 > > > > res_counter_uncharge_locked+0x1f/0x2f() > > > > > > > > Breakage comes from 34c00c319ce7 ("memcg: convert to use cgroup id"). > > > > > > > > The lifetime of a cgroup id is different from the lifetime of the > > > > css id it replaced: memsw's css_get()s do nothing to hold on to the > > > > old cgroup id, it soon gets recycled to a new cgroup, which then > > > > mysteriously inherits the old's swap, without any charge for it. > > > > (I thought memsw's particular need had been discussed and was > > > > well understood when 34c00c319ce7 went in, but apparently not.) > > > > > > > > The right thing to do at this stage would be to revert that and its > > > > associated commits; but I imagine to do so would be unwelcome to > > > > the cgroup guys, going against their general direction; and I've > > > > no idea how embedded that css_id removal has become by now. > > > > > > > > Perhaps some creative refcounting can rescue memsw while still > > > > using cgroup id? > > > > > > > > > > Sorry for the broken. > > > > > > I think we can keep the cgroup->id until the last css reference is > > > dropped and the css is scheduled to be destroyed. > > > > How would this work? The task which pushed the memory to the swap is > > still alive (living in a different group) and the swap will be there > > after the last reference to css as well. > > Or did you mean to get css reference in swap_cgroup_record and release > it in __mem_cgroup_try_charge_swapin? We already do that, swap records hold a css reference. We do the put in mem_cgroup_uncharge_swap(). It really strikes me as odd that we recycle the cgroup ID while there are still references to the cgroup in circulation. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johannes Weiner Subject: Re: 3.13-rc breaks MEMCG_SWAP Date: Mon, 16 Dec 2013 11:41:54 -0500 Message-ID: <20131216164154.GX21724@cmpxchg.org> References: <52AEC989.4080509@huawei.com> <20131216095345.GB23582@dhcp22.suse.cz> <20131216104042.GC23582@dhcp22.suse.cz> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cmpxchg.org; s=zene; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=W7voIUtkannTeaYQqZ9QKW6MYdkqHc18oXztHZQ9LJo=; b=ZTuv+K5oH7q6Z6gcqlJ0bGJutxZivPVN55sFxUoEXwaPcrN5WmSK3GeQZso98hrgo2U0K6vnOE44uwwJQJS1Qi+E9u6rgx706uhnshhQxsfdqYptbMt9ioKU/NsFekHCjjjMnnRmyj/PxZ39LrcyZvMCdjFpZuLwFRY9WTZeKpU=; Content-Disposition: inline In-Reply-To: <20131216104042.GC23582@dhcp22.suse.cz> Sender: owner-linux-mm@kvack.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Michal Hocko Cc: Li Zefan , Hugh Dickins , Tejun Heo , Andrew Morton , KAMEZAWA Hiroyuki , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org On Mon, Dec 16, 2013 at 11:40:42AM +0100, Michal Hocko wrote: > On Mon 16-12-13 10:53:45, Michal Hocko wrote: > > On Mon 16-12-13 17:36:09, Li Zefan wrote: > > > On 2013/12/16 16:36, Hugh Dickins wrote: > > > > CONFIG_MEMCG_SWAP is broken in 3.13-rc. Try something like this: > > > > > > > > mkdir -p /tmp/tmpfs /tmp/memcg > > > > mount -t tmpfs -o size=1G tmpfs /tmp/tmpfs > > > > mount -t cgroup -o memory memcg /tmp/memcg > > > > mkdir /tmp/memcg/old > > > > echo 512M >/tmp/memcg/old/memory.limit_in_bytes > > > > echo $$ >/tmp/memcg/old/tasks > > > > cp /dev/zero /tmp/tmpfs/zero 2>/dev/null > > > > echo $$ >/tmp/memcg/tasks > > > > rmdir /tmp/memcg/old > > > > sleep 1 # let rmdir work complete > > > > mkdir /tmp/memcg/new > > > > umount /tmp/tmpfs > > > > dmesg | grep WARNING > > > > rmdir /tmp/memcg/new > > > > umount /tmp/memcg > > > > > > > > Shows lots of WARNING: CPU: 1 PID: 1006 at kernel/res_counter.c:91 > > > > res_counter_uncharge_locked+0x1f/0x2f() > > > > > > > > Breakage comes from 34c00c319ce7 ("memcg: convert to use cgroup id"). > > > > > > > > The lifetime of a cgroup id is different from the lifetime of the > > > > css id it replaced: memsw's css_get()s do nothing to hold on to the > > > > old cgroup id, it soon gets recycled to a new cgroup, which then > > > > mysteriously inherits the old's swap, without any charge for it. > > > > (I thought memsw's particular need had been discussed and was > > > > well understood when 34c00c319ce7 went in, but apparently not.) > > > > > > > > The right thing to do at this stage would be to revert that and its > > > > associated commits; but I imagine to do so would be unwelcome to > > > > the cgroup guys, going against their general direction; and I've > > > > no idea how embedded that css_id removal has become by now. > > > > > > > > Perhaps some creative refcounting can rescue memsw while still > > > > using cgroup id? > > > > > > > > > > Sorry for the broken. > > > > > > I think we can keep the cgroup->id until the last css reference is > > > dropped and the css is scheduled to be destroyed. > > > > How would this work? The task which pushed the memory to the swap is > > still alive (living in a different group) and the swap will be there > > after the last reference to css as well. > > Or did you mean to get css reference in swap_cgroup_record and release > it in __mem_cgroup_try_charge_swapin? We already do that, swap records hold a css reference. We do the put in mem_cgroup_uncharge_swap(). It really strikes me as odd that we recycle the cgroup ID while there are still references to the cgroup in circulation. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org