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=-1.0 required=3.0 tests=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 11DF5C83000 for ; Tue, 28 Apr 2020 08:05:30 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A9455206B9 for ; Tue, 28 Apr 2020 08:05:29 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A9455206B9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 51A3E8E0005; Tue, 28 Apr 2020 04:05:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4CADE8E0001; Tue, 28 Apr 2020 04:05:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DF7C8E0005; Tue, 28 Apr 2020 04:05:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0242.hostedemail.com [216.40.44.242]) by kanga.kvack.org (Postfix) with ESMTP id 23C068E0001 for ; Tue, 28 Apr 2020 04:05:29 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id CFA805000 for ; Tue, 28 Apr 2020 08:05:28 +0000 (UTC) X-FDA: 76756529136.11.dog74_12b38e95c9c11 X-HE-Tag: dog74_12b38e95c9c11 X-Filterd-Recvd-Size: 4048 Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com [209.85.221.68]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Tue, 28 Apr 2020 08:05:28 +0000 (UTC) Received: by mail-wr1-f68.google.com with SMTP id d17so23504070wrg.11 for ; Tue, 28 Apr 2020 01:05:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cyj8I413BRXu+ODrvcPhF92aJAZy8UZchee8rKBDHnk=; b=h6IJC2HvRB1Nh2a3RkqIN7Yn85Oqs8vNRl+P26pn9/FByCNzFiOTJ/G3Hog1PkM6oV UJZJKA7s1zSmHf/Jg7/J7wlimcm2plZN2uUwyaEO9JsGPgbjGRE22xsjPBazwgp0E7k4 k6AQ7wUcTJVbl2G5iz7i8AxvBeD9DkqW3xOVXLr4Bxthg2+fJQo+/unGEsBZG3oQf0rQ pkzGO7may7JoHX8ZEXSV4jYG0ET9GjJxcY6v/J3AaO0YBBFlH6HjKtDo6w8kR9BYQ6DB sZPgBoXGrZ+fpdiGx6+2aIT8hBrQQbpnNzIAKTnF3s/wXrp+Dl1mqUzGny5vLnH0n0rE 6AGQ== X-Gm-Message-State: AGi0PuZW05TCwlRi3qqs0nZgu07zkbE8u2KB/BYtnNuXoqrnUzgTrSfX 9LWtfBwbbQ9VcvzuXOJ0N68= X-Google-Smtp-Source: APiQypKBU154xjWX4O/b386YshxtnWQlKQ1Yec1xkwo8xp+LgKJRUfmavJ3o3THNzl26gKelaamY8Q== X-Received: by 2002:a5d:634a:: with SMTP id b10mr32499297wrw.263.1588061127264; Tue, 28 Apr 2020 01:05:27 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id j13sm24286851wro.51.2020.04.28.01.05.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 28 Apr 2020 01:05:26 -0700 (PDT) Date: Tue, 28 Apr 2020 10:05:25 +0200 From: Michal Hocko To: Yafang Shao Cc: Johannes Weiner , Andrew Morton , Roman Gushchin , Chris Down , Linux MM Subject: Re: [PATCH 0/3] mm: improve proportional memcg protection Message-ID: <20200428080525.GL28637@dhcp22.suse.cz> References: <20200425152418.28388-1-laoar.shao@gmail.com> <20200427170540.GB29022@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 28-04-20 09:45:27, Yafang Shao wrote: [...] > Seems we can't get an agreement on how to improve current code. > So I will submit a patch to revert the commit 9783aa9917f8 ("mm, > memcg: proportional memory.{low,min} reclaim") first. My current understanding is that the issue we are discussing here is mostly theoretical. Your changelog doesn't really talk about any real life workloads that would be suffering. While it is possible to construct one that misbehaves it is really important to know whether this actually happens in real life. My guess would be that it is not because nax/high limits do not tend to be close to protection usually. With that in mind I do not really believe that reverting 9783aa9917f8 is a reasonable approach. Try to weigh pros and cons of the functionality. Useful functionality for reasonable setups vs. potential corner cases which are not really likely. Please also note that we might disagree on implementation details because people usually have very different taste for code. But it seems that we are in agreement with Johannes that your patch does not really improve the overall situation all that much while it adds stuff that we actively disagree with. So it would be really more helpful to not insist on unrelated implementation details and focus on two things 1) split up the effective values calculation from the predicate (cleanup without any functional changes) 2) make the calculation more robust against racing reclaimers. I plan to get to this unless you beat me to it. -- Michal Hocko SUSE Labs