From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 368A9C43463 for ; Mon, 21 Sep 2020 10:56:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id AC363207BC for ; Mon, 21 Sep 2020 10:56:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="D4rQ16zn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AC363207BC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id D8C3390004C; Mon, 21 Sep 2020 06:56:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D3D26900046; Mon, 21 Sep 2020 06:56:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C55BB90004C; Mon, 21 Sep 2020 06:56:18 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0165.hostedemail.com [216.40.44.165]) by kanga.kvack.org (Postfix) with ESMTP id AEFAC900046 for ; Mon, 21 Sep 2020 06:56:18 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6E689181AEF10 for ; Mon, 21 Sep 2020 10:56:18 +0000 (UTC) X-FDA: 77286764436.03.fog03_2910a8927144 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id 4666D28A4EA for ; Mon, 21 Sep 2020 10:56:18 +0000 (UTC) X-HE-Tag: fog03_2910a8927144 X-Filterd-Recvd-Size: 6367 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by imf36.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 10:56:17 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id z25so14827007iol.10 for ; Mon, 21 Sep 2020 03:56:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5BtOR37a3OHIsYrI7h/K+rcNoAndC5S3VxYKqZAyq/I=; b=D4rQ16znNdt5CP0e41XYbrzCGebWUDkm16H2DmcjT/Bn1mFbg2muRKWYb3/g7roa1Z SIXFKJFiJbvP7v/h0s+Wrgt/QuAVN2/k1Hgtj3vGRVan8w3sk22u5fr84eo5cQiNbf+r 0hgcFmrfBMEoU8uicUxjxxUi6zYoox4fijENrM8bhnEh7kwMGh0Ke7WzzApLwuZ2QM+K TwgSowGJJ36XIJw6wZ4IAQIy0CUnDvalE8cM3hcdOID97NoV5+7ZZMTq2ipat+rmKyP6 ackv0YLVWrdndNJlFGGUL37XSpjFCG8Oci1fiP4tD/3IgS7xCmQHfNcV8qz4wEAn42JA 5CDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5BtOR37a3OHIsYrI7h/K+rcNoAndC5S3VxYKqZAyq/I=; b=MtO1cVjY6moXhqgTtGB4jXWwkdjQ+7WLQb4FHD58tAbMIoeCI5ww6F+f4pph3Zn+Bb wmfL2rMo9EV0iVIFlrJIxy9pmH9APg9RoZTXJex5ra9yHpCa8AxEdVNS6jka6q6F0SZE 15rYYT++BktV8+2vdfmc3VjmGlh41CVEUioWPCRR+OIN17tKzaLsRrPSh0ofYHD+qdSy +0Y6C7XCK9r/uEFpqPayzyc3om7U7C1KVy5hPkNzRKtTcxoSpa9fBWRMqJlRaufIDfL9 naHH0vf6m4eZSJLwQ3oTMMfEZ3/1GmsDdPf9e7Mpel/SCOFru3GMEEbY2a9gYca9nLHj ZKxQ== X-Gm-Message-State: AOAM5327I/IOKorH/wVrseJhSkR1QSxAJhH4Ru6fSbuNIDqPzzbX9YrH w4oO4Le7ip0yQODM1FXSBDdebc0ge8rqOUom3pQ= X-Google-Smtp-Source: ABdhPJx56VNqPYz9Y++kiS/q8eylUU9IYIG298M0UB0Xm4SokD4cg+H0rHxRTuF9Sy0GCffccLLpEZlUksaGhsxwsUo= X-Received: by 2002:a05:6602:21cc:: with SMTP id c12mr35177041ioc.81.1600685777190; Mon, 21 Sep 2020 03:56:17 -0700 (PDT) MIME-Version: 1.0 References: <20200921080255.15505-1-zangchunxin@bytedance.com> <20200921081200.GE12990@dhcp22.suse.cz> In-Reply-To: <20200921081200.GE12990@dhcp22.suse.cz> From: Yafang Shao Date: Mon, 21 Sep 2020 18:55:40 +0800 Message-ID: Subject: Re: [PATCH] mm/memcontrol: Add the drop_cache interface for cgroup v2 To: Michal Hocko Cc: zangchunxin@bytedance.com, Johannes Weiner , Vladimir Davydov , Andrew Morton , Tejun Heo , lizefan@huawei.com, Jonathan Corbet , Alexei Starovoitov , Daniel Borkmann , kafai@fb.com, Song Liu , Yonghong Song , andriin@fb.com, john.fastabend@gmail.com, kpsingh@chromium.org, Cgroups , linux-doc@vger.kernel.org, Linux MM , LKML , netdev , bpf@vger.kernel.org Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Sep 21, 2020 at 4:12 PM Michal Hocko wrote: > > On Mon 21-09-20 16:02:55, zangchunxin@bytedance.com wrote: > > From: Chunxin Zang > > > > In the cgroup v1, we have 'force_mepty' interface. This is very > > useful for userspace to actively release memory. But the cgroup > > v2 does not. > > > > This patch reuse cgroup v1's function, but have a new name for > > the interface. Because I think 'drop_cache' may be is easier to > > understand :) > > This should really explain a usecase. Global drop_caches is a terrible > interface and it has caused many problems in the past. People have > learned to use it as a remedy to any problem they might see and cause > other problems without realizing that. This is the reason why we even > log each attempt to drop caches. > > I would rather not repeat the same mistake on the memcg level unless > there is a very strong reason for it. > I think we'd better add these comments above the function mem_cgroup_force_empty() to explain why we don't want to expose this interface in cgroup2, otherwise people will continue to send this proposal without any strong reason. > > Signed-off-by: Chunxin Zang > > --- > > Documentation/admin-guide/cgroup-v2.rst | 11 +++++++++++ > > mm/memcontrol.c | 5 +++++ > > 2 files changed, 16 insertions(+) > > > > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst > > index ce3e05e41724..fbff959c8116 100644 > > --- a/Documentation/admin-guide/cgroup-v2.rst > > +++ b/Documentation/admin-guide/cgroup-v2.rst > > @@ -1181,6 +1181,17 @@ PAGE_SIZE multiple when read back. > > high limit is used and monitored properly, this limit's > > utility is limited to providing the final safety net. > > > > + memory.drop_cache > > + A write-only single value file which exists on non-root > > + cgroups. > > + > > + Provide a mechanism for users to actively trigger memory > > + reclaim. The cgroup will be reclaimed and as many pages > > + reclaimed as possible. > > + > > + It will broke low boundary. Because it tries to reclaim the > > + memory many times, until the memory drops to a certain level. > > + > > memory.oom.group > > A read-write single value file which exists on non-root > > cgroups. The default value is "0". > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 0b38b6ad547d..98646484efff 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -6226,6 +6226,11 @@ static struct cftype memory_files[] = { > > .write = memory_max_write, > > }, > > { > > + .name = "drop_cache", > > + .flags = CFTYPE_NOT_ON_ROOT, > > + .write = mem_cgroup_force_empty_write, > > + }, > > + { > > .name = "events", > > .flags = CFTYPE_NOT_ON_ROOT, > > .file_offset = offsetof(struct mem_cgroup, events_file), > > -- > > 2.11.0 > > -- > Michal Hocko > SUSE Labs > -- Thanks Yafang