Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1192264imu; Wed, 9 Jan 2019 13:21:52 -0800 (PST) X-Google-Smtp-Source: ALg8bN4Xb/1KzNPsBMp4X63KB6fTSTa/zL4qLD8iE8cOeKGsmQBFX6+gcsbkHhjiwjMhfwYx5Pek X-Received: by 2002:a62:2fc3:: with SMTP id v186mr7586836pfv.82.1547068912137; Wed, 09 Jan 2019 13:21:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547068912; cv=none; d=google.com; s=arc-20160816; b=W61i3rFHdiAA894ZA0igXzD9RdMOC7Kj5dDV4YtuEhS9n8k7zgvN1XY+KQiM1Ypfge MiXACU+QMrKJrMsktqPcpMAHHaD0L4LMc2U1+aWR1AoT+YHTxXqscqcGHns3cgeKDdvK ysgOOatlmSVDSKTECANWPReFusDKz/ygFZWFAS9cM6PLQ2rlAPr0DZGv+VTknekyJJMa h3Y7jWsfyCiwJJx/Y4Ao1GNIdqQz9V7mme4sEdOtsLouNqR7XRf9SZJa7lQon1bEAYfM i/aNnjQr6h9ZG7/50QAhc6g0OD0lHJYUw9486AD28Hqo7IrqZCCPnwPD4FdV4zrf414B V+0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=6Y4P+RH7kDCKB72PEaSDSCp4FAo31tuO+VrSZguuKT0=; b=yFSbKL5jwCprYgb9oJgQgRGWFMWzXz57uR1N6RB82VmpjGER2QlJlDEYhwZoKK5qGv 6CJgMZ8b3NffHXiudPxHsKhzUsMy/MWak5UtvZPnw0xjNENuFhxWfNIZyCvZmsVhf/H1 7XrCEdhdjk/yMSbyShDnE3sxFrskFuvUKEtshzBX/fgfsJ2yBcl11sp4L1zUmb0cCo+O LiY6Ju9C/jxCwKm+wsb9dJjA8fKTFhy7mVia6m8VUKVEUnQleYVeLtieBR8/e2X0jfXw //rlQFgTWnukYL70YC3wp7vNxVooUaf6o5e9bW7fif1sUxjnqz8PvYHdMclfqj9R7eNg 70Yw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l33si8415337pld.142.2019.01.09.13.21.36; Wed, 09 Jan 2019 13:21:52 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728229AbfAITUb (ORCPT + 99 others); Wed, 9 Jan 2019 14:20:31 -0500 Received: from out30-131.freemail.mail.aliyun.com ([115.124.30.131]:34693 "EHLO out30-131.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728143AbfAITUa (ORCPT ); Wed, 9 Jan 2019 14:20:30 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R171e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e01424;MF=yang.shi@linux.alibaba.com;NM=1;PH=DS;RN=7;SR=0;TI=SMTPD_---0THtvvDg_1547061291; Received: from e19h19392.et15sqa.tbsite.net(mailfrom:yang.shi@linux.alibaba.com fp:SMTPD_---0THtvvDg_1547061291) by smtp.aliyun-inc.com(127.0.0.1); Thu, 10 Jan 2019 03:14:59 +0800 From: Yang Shi To: mhocko@suse.com, hannes@cmpxchg.org, shakeelb@google.com, akpm@linux-foundation.org Cc: yang.shi@linux.alibaba.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: [v3 PATCH 4/5] mm: memcontrol: bring force_empty into default hierarchy Date: Thu, 10 Jan 2019 03:14:44 +0800 Message-Id: <1547061285-100329-5-git-send-email-yang.shi@linux.alibaba.com> X-Mailer: git-send-email 1.8.3.1 In-Reply-To: <1547061285-100329-1-git-send-email-yang.shi@linux.alibaba.com> References: <1547061285-100329-1-git-send-email-yang.shi@linux.alibaba.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The default hierarchy doesn't support force_empty, but there are some usecases which create and remove memcgs very frequently, and the tasks in the memcg may just access the files which are unlikely accessed by anyone else. So, we prefer force_empty the memcg before rmdir'ing it to reclaim the page cache so that they don't get accumulated to incur unnecessary memory pressure. Since the memory pressure may incur direct reclaim to harm some latency sensitive applications. There is another patch which introduces asynchronous memory reclaim when offlining, but the behavior of force_empty is still needed by some usecases which want to get the memory reclaimed immediately. So, bring force_empty interface in default hierarchy too. Cc: Michal Hocko Cc: Johannes Weiner Cc: Shakeel Butt Signed-off-by: Yang Shi --- Documentation/admin-guide/cgroup-v2.rst | 14 ++++++++++++++ mm/memcontrol.c | 4 ++++ 2 files changed, 18 insertions(+) diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 7bf3f12..0290c65 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1289,6 +1289,20 @@ PAGE_SIZE multiple when read back. Shows pressure stall information for memory. See Documentation/accounting/psi.txt for details. + memory.force_empty + This interface is provided to make cgroup's memory usage empty. + When writing anything to this + + # echo 0 > memory.force_empty + + the cgroup will be reclaimed and as many pages reclaimed as possible. + + The typical use case for this interface is before calling rmdir(). + Though rmdir() offlines memcg, but the memcg may still stay there due to + charged file caches. Some out-of-use page caches may keep charged until + memory pressure happens. If you want to avoid that, force_empty will be + useful. + Usage Guidelines ~~~~~~~~~~~~~~~~ diff --git a/mm/memcontrol.c b/mm/memcontrol.c index ff50810..5d42a19 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -5743,6 +5743,10 @@ static ssize_t memory_oom_group_write(struct kernfs_open_file *of, .seq_show = wipe_on_offline_show, .write_u64 = wipe_on_offline_write, }, + { + .name = "force_empty", + .write = mem_cgroup_force_empty_write, + }, { } /* terminate */ }; -- 1.8.3.1