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=-3.6 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no 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 8EA93C43464 for ; Mon, 21 Sep 2020 11:23:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 354B920EDD for ; Mon, 21 Sep 2020 11:23:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nqLrdxvY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 354B920EDD 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 7C385900050; Mon, 21 Sep 2020 07:23:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74E23900046; Mon, 21 Sep 2020 07:23:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61500900050; Mon, 21 Sep 2020 07:23:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0039.hostedemail.com [216.40.44.39]) by kanga.kvack.org (Postfix) with ESMTP id 45F61900046 for ; Mon, 21 Sep 2020 07:23:40 -0400 (EDT) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 042EA8249980 for ; Mon, 21 Sep 2020 11:23:40 +0000 (UTC) X-FDA: 77286833400.17.rub49_130ab8327144 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 0ECBB180D0185 for ; Mon, 21 Sep 2020 11:23:38 +0000 (UTC) X-HE-Tag: rub49_130ab8327144 X-Filterd-Recvd-Size: 5900 Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by imf46.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Sep 2020 11:23:38 +0000 (UTC) Received: by mail-il1-f193.google.com with SMTP id y8so12958186ilm.11 for ; Mon, 21 Sep 2020 04:23:38 -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=Jylsjxure8iloHgTv6dK8e3IpVuFYGMIH7w1sVGlBAw=; b=nqLrdxvYUsrTTUgEz8hFcvRTwfimgRk7PIAWUsvqWfJXTlPGfflwm8mzXT8aa2KY2P 68uE0ItUG43PEBQHvQz0n5LfzcY5Vinp3+0+N/mi9FzOG6wN7RalWfeVlXnWsudjvjLp azA/VpQMdPVNfv0XmXevqqOz8FpUze8tuIoBUenMuu9HhVDRlzMDoeTwUTGMvMguTp/z 8XEmLlOEvu1vFSu26V/SA8TWV2zWBUcmtuQOOj/8mT/j0oWnquMpxzpvNWBy+D2FVLw5 URhzLqfaOkxtFGFL0xgduy16DEHqIIA4K/3Dp3aKV72mKsmud58QrDiQCeOAcPvNt6ik /HCA== 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=Jylsjxure8iloHgTv6dK8e3IpVuFYGMIH7w1sVGlBAw=; b=naXYatlPeZJq7NfCBg4WPE6zE4jM3KyoyXkOG74e6PdFBqZIPcwA0/IINoVE2/n7Nf VN1aEKrjAYFihIjEbfL0BzV1BX961ehkHMx4/qK0iehGr7fgaerPJ9g5UQqk0rUsVPAT J/Jrkk+bed8shhPBWneSxuKT4GFjeT8jIFmtD7Lo0L02mxSZNp50ts3IbclM5CxW0sLP Nt28GOYkwE4qi3MV4KfvfQMkUm33ck2ITMTVhGNJG9ydfO7OIu4aLZUvQst2kRmHP64M KU4zmcJKh8nrSOpX3Xl2V2cVbA6PWkl0NetSUutetJfZTyMYUC7BXG/y9HrXX6US/MOw mabA== X-Gm-Message-State: AOAM531B6EKk0Ejpfydn9BG7dTTnDeAD/kaJZH2IxOXOECZQa1GQ1dKo 9iKrBDaREwvL73b1OPB1tYjtq+qQmpTTG8qcLGY= X-Google-Smtp-Source: ABdhPJxKB3sTltABNKXrNPF1O/jcVNZisQ+S96LJnMDeQtk1GgN0zbXDBpIBy0vCshMqNA00/xnM1su+7h8kUnV4ny0= X-Received: by 2002:a92:c7b0:: with SMTP id f16mr41703231ilk.137.1600687417526; Mon, 21 Sep 2020 04:23:37 -0700 (PDT) MIME-Version: 1.0 References: <20200921080255.15505-1-zangchunxin@bytedance.com> <20200921081200.GE12990@dhcp22.suse.cz> <20200921110505.GH12990@dhcp22.suse.cz> In-Reply-To: <20200921110505.GH12990@dhcp22.suse.cz> From: Yafang Shao Date: Mon, 21 Sep 2020 19:23:01 +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 7:05 PM Michal Hocko wrote: > > On Mon 21-09-20 18:55:40, Yafang Shao wrote: > > 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. > > I do not mind people sending this proposal. "V1 used to have an > interface, we need it in v2 as well" is not really viable without > providing more reasoning on the specific usecase. > > _Any_ patch should have a proper justification. This is nothing really > new to the process and I am wondering why this is coming as a surprise. > Container users always want to drop cache in a specific container, because they used to use drop_caches to fix memory pressure issues. Although drop_caches can cause some unexpected issues, it could also fix some issues. So container users want to use it in containers as well. If this feature is not implemented in cgroup, they will ask you why but there is no explanation in the kernel. Regarding the memory.high, it is not perfect as well, because you have to set it to 0 to drop_caches, and the processes in the containers have to reclaim pages as well because they reach the memory.high, but memory.force_empty won't make other processes to reclaim. That doesn't mean I agree to add this interface, while I really mean that if we discard one feature we'd better explain why. -- Thanks Yafang