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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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 B4379C4727F for ; Tue, 22 Sep 2020 09:44:08 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 02C01221F0 for ; Tue, 22 Sep 2020 09:44:07 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=bytedance-com.20150623.gappssmtp.com header.i=@bytedance-com.20150623.gappssmtp.com header.b="HrhPC/cS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 02C01221F0 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 1575E900040; Tue, 22 Sep 2020 05:44:07 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0E1CB900036; Tue, 22 Sep 2020 05:44:07 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EEBDA900040; Tue, 22 Sep 2020 05:44:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0077.hostedemail.com [216.40.44.77]) by kanga.kvack.org (Postfix) with ESMTP id D57D0900036 for ; Tue, 22 Sep 2020 05:44:06 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8BB45180AD801 for ; Tue, 22 Sep 2020 09:44:06 +0000 (UTC) X-FDA: 77290211292.12.hope34_241023d2714c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 6A9501805408D for ; Tue, 22 Sep 2020 09:44:06 +0000 (UTC) X-HE-Tag: hope34_241023d2714c X-Filterd-Recvd-Size: 6083 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf18.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Sep 2020 09:44:05 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id k25so13589182ljk.0 for ; Tue, 22 Sep 2020 02:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=guVVaBxnWrQ86fDPccANXl4ruP0cfa0fdBrEFJjzk2w=; b=HrhPC/cSVDNvm9kRZbwXzKjP6DTk7b2Nny0qurmlykw8pbZ55EM/YwnTphGw0Phb0i zLX5bT+td8tZrb0mEVN/5fL82j/z07O92s3jT9d8a3W4dm57qRVrcwJUKb/E954BVUFV TFAFWTS9f1YWrkJmJXHSfoOpeRSQND+w5H5Fjv8qHCsv7cOPHBTyoHb2k7c4eymMDFdn 36bHMIDD9tsCIpE+KTz3b5R3eCf65PHRjGW/uP65gLuixUJGJ3T+62IcXjI47ThEu5eZ VV1igHblTySvW9p8oAXIc5QU5B9pDzu/21y96VHJGLYi8awC0gVsJZPlzCzJkQh6mF7V 96iw== 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:content-transfer-encoding; bh=guVVaBxnWrQ86fDPccANXl4ruP0cfa0fdBrEFJjzk2w=; b=adljOoA0HIdbevgMOumDIkRgISl21or6KZS6tzSKdLAQ8cbkwdUbBFACA9m/tDw5d5 5w5+/cGKYyi7wOUFZoHkXhyEWfzjuUi0rLr75KrqRgEeBIA6RmU5yhazymL5Np6MspdO PoN8CwAzjIp/B0ZDxP9SE9l8naB3sngRfh0J46uA4Yd71gGmKDVEk7ZEGfle8QMFrvE9 UmSDo4gxV7FBLB+in4sI/SQGKDmxsTHNtuRA+H9t60vx68sHX7HXi7Coa2karBeLCZdh Dcm3Ri1HggG5oXQL5M3iG8YfDRe/jqcyu2PfQg5YxByJbg5EV6nDaLCSiv5IPujmdxyt id6w== X-Gm-Message-State: AOAM533IY6/NQZJGqwHzW+jFDwlTI3b+PN7uspKVmmIkZ6tpaQBsjkmK i3dqnRSRgnm1YPskAZ1eSuknA7Sdo5BOw1QmnsNy4Q== X-Google-Smtp-Source: ABdhPJxXVnl7GUvUOwrcD+5qdd9k2lu/yskeXQOKLRd98NXH9jTfBpsWC5OGIMBrUFqa0KDjRh3xVSSaQ18LIv9nGbI= X-Received: by 2002:a2e:b8d1:: with SMTP id s17mr1198265ljp.222.1600767843752; Tue, 22 Sep 2020 02:44:03 -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: Chunxin Zang Date: Tue, 22 Sep 2020 17:43:52 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm/memcontrol: Add the drop_cache interface for cgroup v2 To: Michal Hocko Cc: Yafang Shao , 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" Content-Transfer-Encoding: quoted-printable 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 terribl= e > > > 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. > I'm so sorry for that. My usecase is that there are two types of services in one server. They have difference priorities. Type_A has the highest priority, we need to ensure it's schedule latency=E3=80=81I/O latency=E3=80=81memory enough. Type_B has the lowest priority, we expect it will not affect Type_A when executed. So Type_A could use memory without any limit. Type_B could use memory only when the memory is absolutely sufficient. But we cannot estimate how much memory Type_B should use. Because everything is dynamic. So we can't set Type_B's memory.high. So we want to release the memory of Type_B when global memory is insufficient in order to ensure the quality of service of Type_A . In the past, we used the 'force_empty' interface of cgroup v1. > -- > Michal Hocko > SUSE Labs Best wishes Chunxin