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 6674FC4727D for ; Tue, 22 Sep 2020 12:37:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id C6A362395C for ; Tue, 22 Sep 2020 12:37:46 +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="GReCqit5" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C6A362395C 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 0E3C0900076; Tue, 22 Sep 2020 08:37:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 09601900063; Tue, 22 Sep 2020 08:37:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9EDF900076; Tue, 22 Sep 2020 08:37:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0183.hostedemail.com [216.40.44.183]) by kanga.kvack.org (Postfix) with ESMTP id D3220900063 for ; Tue, 22 Sep 2020 08:37:45 -0400 (EDT) Received: from smtpin05.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 93420362D for ; Tue, 22 Sep 2020 12:37:45 +0000 (UTC) X-FDA: 77290648890.05.lace34_1714d142714d Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin05.hostedemail.com (Postfix) with ESMTP id 72F5C18014D27 for ; Tue, 22 Sep 2020 12:37:45 +0000 (UTC) X-HE-Tag: lace34_1714d142714d X-Filterd-Recvd-Size: 6110 Received: from mail-lj1-f196.google.com (mail-lj1-f196.google.com [209.85.208.196]) by imf30.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Sep 2020 12:37:44 +0000 (UTC) Received: by mail-lj1-f196.google.com with SMTP id k25so14003099ljk.0 for ; Tue, 22 Sep 2020 05:37:44 -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=gA220xpuIaxUuyuMwr6nlukSuBX7MpFrxgJa3f1luDw=; b=GReCqit5HTO/ziRjftty0K8XZi2ySCuJzKJveaG0MdXTTpgULihVLwMvfADeawU2QZ IbAydMl3Tn/9XZF79/7c4WOv1D9hB06rNVFZ/DiHhbarrKyedLyRCcCrKNAAgAgynsvl PuiO+M0DWum3yqYFnTFuppHoZ6RUqQ5x1aZtz6a6hAJDQtyZm8Nk5IuIu/m6lV5zU0Qa YPhNCDslcn72ErQ130linofe9GJPNOAEaCIrlopykwgfmAJg0zLWoF20Oug79KD1o/ie h0iyMZUYd3e33ZiaWMrDN63XT+TuA6+CR0zCHGKr/FQJkVpg0EeSRf5Qih1CxKrTnkq8 Ut5Q== 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=gA220xpuIaxUuyuMwr6nlukSuBX7MpFrxgJa3f1luDw=; b=f/2Hg7RWPS7/MQ0Zkid7Qu2ey9Lu/L3tZi6oDOB9mv04zo+agymJfv1gf4DhGZpYMV aI0o8dN8pfl/yY/aC+s9mcc7Uema53kcDR1T2dILUH93c8xX9miYlfwQCVztKUfvkaYF D5GcmDFBa0VkpE1/xegypZa6+38TeVTKWxt8eCzB1nwlX+a5iBrfDs7KKTrTOA+gYt4R xPlYamzRBAEs6viZsOropHvHSzzrx9+JskBgJSp+P0dlKl2UkI12BZa65npKvM9/tC4j oBm+cQQJf9RQYWGKENszbvRuNV8sepkhYQbSK+6ODEhHunwZGQc3sXMvfNE0V/R/1YVn iv7A== X-Gm-Message-State: AOAM530fsboJTlr+Q33cXpo6xcKKeSKfa5TAZRl/QDjIn+ZDXOztolv9 /6AWECDDq/qQxC7yaV27/7/6TKfmdySo2mxZwk2I3Q== X-Google-Smtp-Source: ABdhPJy2uCCGncfmVCuod/IiCiTTfxrKsDOlJTrFdVxVRrWlq7JKLI4j/OgY4j/S5nJzpdTEsCyW0xWnIGQadAicUpY= X-Received: by 2002:a2e:9089:: with SMTP id l9mr1605962ljg.408.1600778262989; Tue, 22 Sep 2020 05:37:42 -0700 (PDT) MIME-Version: 1.0 References: <20200921080255.15505-1-zangchunxin@bytedance.com> <20200921081200.GE12990@dhcp22.suse.cz> <20200921110505.GH12990@dhcp22.suse.cz> <20200922095136.GA9682@chrisdown.name> <20200922104252.GB9682@chrisdown.name> In-Reply-To: <20200922104252.GB9682@chrisdown.name> From: Chunxin Zang Date: Tue, 22 Sep 2020 20:37:32 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm/memcontrol: Add the drop_cache interface for cgroup v2 To: Chris Down Cc: Michal Hocko , 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 Tue, Sep 22, 2020 at 6:42 PM Chris Down wrote: > > Chunxin Zang writes: > >On Tue, Sep 22, 2020 at 5:51 PM Chris Down wrote: > >> > >> Chunxin Zang writes: > >> >My usecase is that there are two types of services in one server. The= y > >> >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 exp= ect 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.h= igh. > >> > > >> >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. > >> > >> This sounds like a perfect use case for memory.low on Type_A, and it's= pretty > >> much exactly what we invented it for. What's the problem with that? > > > >But we cannot estimate how much memory Type_A uses at least. > > memory.low allows ballparking, you don't have to know exactly how much it= uses. > Any amount of protection biases reclaim away from that cgroup. > > >For example: > >total memory: 100G > >At the beginning, Type_A was in an idle state, and it only used 10G of m= emory. > >The load is very low. We want to run Type_B to avoid wasting machine res= ources. > >When Type_B runs for a while, it used 80G of memory. > >At this time Type_A is busy, it needs more memory. > > Ok, so set memory.low for Type_A close to your maximum expected value. Please forgive me for not being able to understand why setting memory.low for Type_A can solve the problem. In my scene, Type_A is the most important, so I will set 100G to memory.low= . But 'memory.low' only takes effect passively when the kernel is reclaiming memory. It means that reclaim Type_B's memory only when Type_A in alloc memory slow path. This will affect Type_A's performance. We want to reclaim Type_B's memory in advance when A is expected to be busy= . Best wishes Chunxin