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=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 93DBAC54FD0 for ; Mon, 27 Apr 2020 10:10:05 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4CF9A206D6 for ; Mon, 27 Apr 2020 10:10:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="qBkxqlr0" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4CF9A206D6 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 CC59C8E0005; Mon, 27 Apr 2020 06:10:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C4EB68E0001; Mon, 27 Apr 2020 06:10:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AEF318E0005; Mon, 27 Apr 2020 06:10:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0217.hostedemail.com [216.40.44.217]) by kanga.kvack.org (Postfix) with ESMTP id 92FBB8E0001 for ; Mon, 27 Apr 2020 06:10:04 -0400 (EDT) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 501D72488 for ; Mon, 27 Apr 2020 10:10:04 +0000 (UTC) X-FDA: 76753214328.22.twig36_1daee78c39e21 X-HE-Tag: twig36_1daee78c39e21 X-Filterd-Recvd-Size: 5357 Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by imf10.hostedemail.com (Postfix) with ESMTP for ; Mon, 27 Apr 2020 10:10:03 +0000 (UTC) Received: by mail-il1-f196.google.com with SMTP id r2so16120630ilo.6 for ; Mon, 27 Apr 2020 03:10:03 -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=GQF/UV+KB+5n6QugmJTjkjA0FvnIlru85YG080EJBuE=; b=qBkxqlr0itIofb0tpER7FfLFQdP29FZ4h4dvErFoAxMt6+FBtUVy/ZvkdieO1pHPMw Vz+SxdBhkPcyMKHzqtz7IzamuQPF1gtmb7kuRzU1GvyrhJFXtSSfbSLcc6b9WOtcveWW Klq5A0XtYSeKvnoEOKEjDJ+Uc+Vcfqt1uzADbXUPMxHnX0qcfWj1Ty4BUDB/5/1chzRM aWx4yf6ji/bMC9tF0RDqkkIzV743nglYDJgJK2Tb4cWJXApBFeX4lpTiuU3ymVbKcwpF n2liMkXD1lbHbkER7iq9H2qdUYyBoaH5LPNavlM3x9czu1nSlC9OVBFfKmbyrV0gH//b B+4Q== 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=GQF/UV+KB+5n6QugmJTjkjA0FvnIlru85YG080EJBuE=; b=XiZny4kxs5ViAtNHmRXehIlTUcCdNLErfily0qOBUZWr33VD8/i5zj0dr1Xus6+ecI U0EQe/LtvAhIA+a0dLN3Sbee3OmVuXPRbeQ2jHPdvQhaaU87CywimpTVyPrDXyeKEPzX e3jT0fnW5cwSB6nnDYxm+DnAeh4WZaClprGdSuxuEVrJXmLnNbFdyY/DzBORVtp16aPH r01Qxf9fyblwEow46NvSLm6B6M348ePT8I5jHTt/yq392IrOfk1BxT9umft6Ex9MCAz9 k+zIUsggOgFsSTDtsI4LeOkpKXCdeNyMJbYDyX2wFehGZwu/XUZuWUnEoPTjya6Kittr LUzQ== X-Gm-Message-State: AGi0PuZv2ZNr7klnHIhwmawp07kVor36s9mdAT6niOGcaIJsMTy+9LxY kAXjtu8iLnY6F5JdeTYU7qkzaF8Tj08MXne+2HM= X-Google-Smtp-Source: APiQypJ/ewHxNqy3aNQOZ5jCXjAbEqDE1JeBaWJSfXvAmbEAiBtGgo1LCkBFGpnj6+l4lSqEULN8h0G1RGC7jErgTXY= X-Received: by 2002:a92:1b91:: with SMTP id f17mr20130615ill.142.1587982203331; Mon, 27 Apr 2020 03:10:03 -0700 (PDT) MIME-Version: 1.0 References: <20200425152418.28388-1-laoar.shao@gmail.com> <20200425152418.28388-4-laoar.shao@gmail.com> <20200427094006.GD28637@dhcp22.suse.cz> In-Reply-To: <20200427094006.GD28637@dhcp22.suse.cz> From: Yafang Shao Date: Mon, 27 Apr 2020 18:09:27 +0800 Message-ID: Subject: Re: [PATCH 3/3] mm: improvements on memcg protection functions To: Michal Hocko Cc: Andrew Morton , Johannes Weiner , Roman Gushchin , Chris Down , Linux MM 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, Apr 27, 2020 at 5:40 PM Michal Hocko wrote: > > On Sat 25-04-20 11:24:18, Yafang Shao wrote: > > Since proportional memory.{min, low} reclaim is introduced in > > commit 9783aa9917f8 ("mm, memcg: proportional memory.{low,min} reclaim"), > > it have been proved that the proportional reclaim is hard to understand and > > the issues caused by it is harder to understand.[1]. That dilemma faced by > > us is caused by that the proportional reclaim mixed up memcg and the > > reclaim context. > > > > In proportional reclaim, the whole reclaim context - includes the memcg > > to be reclaimed and the reclaimer, should be considered, rather than > > memcg only. > > > > To make it clear, a new member 'protection' is introduced in the reclaim > > context (struct shrink_control) to replace mem_cgroup_protection(). This > > s@shrink_control@scan_control@ > Thanks for pointing this out. > > one is set when we check whether the memcg is protected or not. > > > > After this change, the issue pointed by me[1] - a really old left-over > > value can slow donw target reclaim - can be fixed, and I think it could > > also avoid some potential race. > > The patch would have been much esier to review if you only focused on > the effective protection value caching. I really fail to see why you had > to make mem_cgroup_protected even more convoluted with more side effects > (e.g. sc->memcg_low_skipped). This goes directly opposite to what > Johannes was proposing in other email AFAICS. > Sorry, I failed to see what the advantage of Johannes's proposal except the better naming. > Your changelog doesn't explain why double caching the effective value is > an improvement. The improvement is, to avoid getting an wrong value calculated by other reclaimers and avoid issues in mem_cgroup_protection() that we haven't noticed. > I believe your goal was to drop the special casing for > the reclaim targets which are the only to ignore protection as they are > clearly violating the consumption constraints. This makes some sense > to me because it makes the special case have a local effect. > > But I really dislike your patch. Please follow up on Johannes' > suggestion to split up the mem_cgroup_protected into parts > http://lkml.kernel.org/r/20200424134438.GA496852@cmpxchg.org > As I said above, I failed to see the advantage of this proposal. Maybe we can wait until Johannes can show his code. Hi Johannes, Would you pls. show a simple implementation on your proposal ASAP ? -- Thanks Yafang