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=-11.4 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_IN_DEF_DKIM_WL 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 2E2F3C4727C for ; Tue, 22 Sep 2020 19:57:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id C85B9221E8 for ; Tue, 22 Sep 2020 19:57:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="c9Y5X31I" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726749AbgIVT5i (ORCPT ); Tue, 22 Sep 2020 15:57:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726720AbgIVT5e (ORCPT ); Tue, 22 Sep 2020 15:57:34 -0400 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 591BEC0613D0 for ; Tue, 22 Sep 2020 12:57:34 -0700 (PDT) Received: by mail-lj1-x242.google.com with SMTP id s205so15183240lja.7 for ; Tue, 22 Sep 2020 12:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Z6CQ4PR7LXXUvvSI+PnJV2oiFyZAUecU41+cGfwOujU=; b=c9Y5X31ITFROkCz58BWDmVOTUSXQxwKVO0+YO5gM7Dueho0fqdMOddqGunqR3K1DSz koftFlaQy5AWDynEFTUKrj/IhzVPvGkhTp5Nxa+Zlib8R9NmI9XnuBG9iHCHh7KcMQ/B R2VvMWJxVq3CuEFElE+lE4DkpmSBO4nOKPEAgpV6PF+cdQ0sJlc2ScNbTbgx8wIlp+Dj kZAs1jbuzLo5f/4MpCexanAo64EI9+2+h41TrGEHG8twyTTttEPJrctB/YnAZ2+HkB5k uWovA5v2eCiXYkMwI/ZVzbxoqj8LOi8G4gzoBn6tiRDAJ7YqjH0xAUIYJg7tM5JKyukd +iUg== 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=Z6CQ4PR7LXXUvvSI+PnJV2oiFyZAUecU41+cGfwOujU=; b=UwtrpIE8/QgQNg3dBzIcD0rhvaNp/pUcVYRNvNypIJgtIkecFcgVEHQgpmxGiwFC+r 9A1Hlsd+ODaMNGwkdZdCHGDFHJEayDCMqVmQTwtWgy6IbuYzyhALtdARtCLqOv8QH+Lu +MvikvifS0I60NZewB14Kx0tNn2EmmA+YPVKoC0KviER46OxtCSPqsqINGTJvlgWppt0 CR7Vtfa3ZMYPaPKzHy1C7oKsN16kCViXs1Xu8DhhyRF5MT0XnSR8yL4OxdCPpyXC5M4C M2h50/1Qs3JPQfGuX3mmBne8+ZAz1h3aMX14UhGmWx+3OLeLwHREvjJI2fVH47lUtkek 9XLA== X-Gm-Message-State: AOAM533VT/OXvxoYEFHv2Xf22JwUUYzlNWEvtFqvGbUVy/1Jg29Z/eFO m7Fu+IMBZ1z/614V9CzBU+Kk5Uito6nuAt84osoogg== X-Google-Smtp-Source: ABdhPJzYews2Ih4OsV/9BJPJX66ITSb1cl147pd8KN4Cqs6H0ueYwNCOPq7ksxkbE9zvtTGB9qj/7KwbIsYjwO4rXFQ= X-Received: by 2002:a2e:7c09:: with SMTP id x9mr1916202ljc.192.1600804651550; Tue, 22 Sep 2020 12:57:31 -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: Shakeel Butt Date: Tue, 22 Sep 2020 12:57:19 -0700 Message-ID: Subject: Re: [External] Re: [PATCH] mm/memcontrol: Add the drop_cache interface for cgroup v2 To: Chunxin Zang 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Sep 22, 2020 at 5:37 AM Chunxin Zang wr= ote: > > 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 wrot= e: > > >> > > >> Chunxin Zang writes: > > >> >My usecase is that there are two types of services in one server. T= hey > > >> >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 e= xpect it > > >> >will not affect > > >> >Type_A when executed. > > >> >So Type_A could use memory without any limit. Type_B could use memo= ry > > >> >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 t= he > > >> >'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= memory. > > >The load is very low. We want to run Type_B to avoid wasting machine r= esources. > > >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.l= ow. > 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 bu= sy. > How will you know when to reclaim from B? Are you polling /proc/meminfo? >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? 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