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 B966EC4363D for ; Wed, 23 Sep 2020 02:41:14 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 50D962087D for ; Wed, 23 Sep 2020 02:41:14 +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="D48LKiLW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 50D962087D 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 782B66B0074; Tue, 22 Sep 2020 22:41:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 734486B0075; Tue, 22 Sep 2020 22:41:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 623676B0078; Tue, 22 Sep 2020 22:41:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id 4606D6B0074 for ; Tue, 22 Sep 2020 22:41:13 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 0470D180AD804 for ; Wed, 23 Sep 2020 02:41:13 +0000 (UTC) X-FDA: 77292774426.11.bean35_0016d4227152 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin11.hostedemail.com (Postfix) with ESMTP id D3DE9180F8B80 for ; Wed, 23 Sep 2020 02:41:12 +0000 (UTC) X-HE-Tag: bean35_0016d4227152 X-Filterd-Recvd-Size: 7813 Received: from mail-lj1-f193.google.com (mail-lj1-f193.google.com [209.85.208.193]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Wed, 23 Sep 2020 02:41:12 +0000 (UTC) Received: by mail-lj1-f193.google.com with SMTP id v23so15905436ljd.1 for ; Tue, 22 Sep 2020 19:41:12 -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=jc8uPyWeA8lh2ZEVJXFhzEZM6SYIOAImDuM4KwfSrTg=; b=D48LKiLW724RXEbvVDcCcvfb/bjfn6Fz7yz848goAqBzaGa96OEdXkzKjJWrEmtr2B u1Ww6BlgX5m69XKUjtHN8FSlwIlBBUpYuv+Iprcmx2j45NU7WOcpX7v16h5UuMpNF38e rsVxKDi8d64KgOP8GtIFzSYqLc0BiBaOMx2UDviVVwCnG96aL140S/UQe+emedYdhZEg hLu/zoRv1FrpWJxCY41I5V0IOBitx8WcSRot3JvqOKnLgKIvj1M9XJRrffwtrDXr8TdH 22yXODro1beLbWdfHb8BQK9j1iuDsUBHVXXEoj11HOHfDNHMT70/R3FvWVOmVx7rcYUS MoMw== 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=jc8uPyWeA8lh2ZEVJXFhzEZM6SYIOAImDuM4KwfSrTg=; b=J5wTil2eNHXaVvc1SfdqoeGFe/g65TI+3dkJ9XyJ16CF6qjJ8FlLpIGBxkLpk0/wUn 78m3g1o03oVIlCHwwOsFlCmZQhL+qa0LDgzL5zHocxAMKa635BSrcI06NEXIqafnkvkw pPGhriu5300GkDY/oHlxYjds5UZXBYAdc8UHyMlc3Q1YF4r8fZIzS8SnAlpSFuIoLiLb l6X26ynvffrRiqPvNzcaKJj51iJ4CulnbqixUSvhRjJrnDasXCaZ4AKSVpXk//MT4I+o IIzBXBotWABVTOEntb1TcBuzIMRiksx4H11PGqtB8pWDj8IreaBFlsg5Vn9I62S9iHIW f0pg== X-Gm-Message-State: AOAM530mM8NbZu9dHQL+SvURS7IJeUpuDnLtk6j6g/fh9+j8v2tjFw8o omUG6r90fCAQxmwI5P+TNJXLrjTuf3PGAJPpGk/gvw== X-Google-Smtp-Source: ABdhPJwQf9C/dYCgdMs0kvxVPlQBoNh6rC23MBqQ+8aghqCHQkwJBsaQqfGzXUr350qTd1zXmvtw67PsWspk7HwJrUc= X-Received: by 2002:a2e:889a:: with SMTP id k26mr2388797lji.214.1600828870825; Tue, 22 Sep 2020 19:41:10 -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: From: Chunxin Zang Date: Wed, 23 Sep 2020 10:40:59 +0800 Message-ID: Subject: Re: [External] Re: [PATCH] mm/memcontrol: Add the drop_cache interface for cgroup v2 To: Shakeel Butt Cc: Chris Down , Michal Hocko , Yafang Shao , Johannes Weiner , Vladimir Davydov , Andrew Morton , Tejun Heo , Li Zefan , 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.011455, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Sep 23, 2020 at 3:57 AM Shakeel Butt wrote: > > On Tue, Sep 22, 2020 at 5:37 AM Chunxin Zang = wrote: > > > > 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 wr= ote: > > > >> > > > >> Chunxin Zang writes: > > > >> >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 me= mory > > > >> >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 memo= ry.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. > > > >> > > > >> 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 muc= h 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 memory. > > > >The load is very low. We want to run Type_B to avoid wasting machine= resources. > > > >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. > > > > How will you know when to reclaim from B? Are you polling /proc/meminfo? > Monitor global memory usage through the daemon. If the memory is used 80% or 90%, it will reclaim B's memory. > From what I understand, you want to proactively reclaim from B, so > that A does not go into global reclaim and in the worst case kill B, > right? Yes, it is. > > BTW you can use memory.high to reclaim from B by setting it lower than > memory.current of B and reset it to 'max' once the reclaim is done. > Since 'B' is not high priority (I am assuming not a latency sensitive > workload), B hitting temporary memory.high should not be an issue. > Also I am assuming you don't much care about the amount of memory to > be reclaimed from B, so I think memory.high can fulfil your use-case. > However if in future you decide to proactively reclaim from all the > jobs based on their priority i.e. more aggressive reclaim from B and a > little bit reclaim from A then memory.high is not a good interface. > > Shakeel Thanks for these suggestions, I will give it a try. Best wishes Chunxin