From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg0-f72.google.com (mail-pg0-f72.google.com [74.125.83.72]) by kanga.kvack.org (Postfix) with ESMTP id 14D556B02F3 for ; Thu, 10 Aug 2017 05:28:59 -0400 (EDT) Received: by mail-pg0-f72.google.com with SMTP id y129so1894494pgy.1 for ; Thu, 10 Aug 2017 02:28:59 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com. [2607:f8b0:400e:c05::22a]) by mx.google.com with ESMTPS id l21si3920574pfj.297.2017.08.10.02.28.58 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 10 Aug 2017 02:28:58 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id l64so669174pge.5 for ; Thu, 10 Aug 2017 02:28:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20170810071059.GC23863@dhcp22.suse.cz> <20170810081920.GG23863@dhcp22.suse.cz> From: wang Yu Date: Thu, 10 Aug 2017 17:28:57 +0800 Message-ID: Subject: Re: memcg Can't context between v1 and v2 because css->refcnt not released Content-Type: text/plain; charset="UTF-8" Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko Cc: Johannes Weiner , Tejun Heo , cgroups@vger.kernel.org, linux-mm@kvack.org 2017-08-10 16:26 GMT+08:00 wang Yu : > 2017-08-10 16:19 GMT+08:00 Michal Hocko : >> [Please do not top-post] >> >> On Thu 10-08-17 16:10:45, wang Yu wrote: >>> at first ,thanks for your reply. >>> but i also tested what you said, the problem is also. >>> force_empty only call try_to_free_pages, not all the pages remove >>> because mem_cgroup_reparent_charges moved >> >> Right. An alternative would be dropping the page cache globaly via >> /proc/sys/vm/drop_caches. Not an ideal solution but it should help. >> -- >> Michal Hocko >> SUSE Labs > > thanks again, but /proc/sys/vm/drop_caches can't solve it > you can try as follow > > #cat /proc/cgroups > > memory 11 2 1 > > #mkdir a > > #echo 0 > a/cgroup.procs > > #sleep 1 > > #echo 0 > cgroup.procs > > #echo 1 > a/memory.force_empty > > #echo 3 > /proc/sys/vm/drop_caches > > #rmdir a > > #cat /proc/cgroups > > memory 11 3 1 > the num_cgroups not decrease and i found that, after drop cache after drop caches, memory.stat shows not pages belong the group, but memory.usage_in_bytes not zero, so maybe other pages has wrong to belong this cgroup -- 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