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 0F60DC55191 for ; Fri, 24 Apr 2020 10:40:46 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B46DC20776 for ; Fri, 24 Apr 2020 10:40:45 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B46DC20776 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 1133B8E0005; Fri, 24 Apr 2020 06:40:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C46E8E0003; Fri, 24 Apr 2020 06:40:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F1BC88E0005; Fri, 24 Apr 2020 06:40:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0020.hostedemail.com [216.40.44.20]) by kanga.kvack.org (Postfix) with ESMTP id D69388E0003 for ; Fri, 24 Apr 2020 06:40:44 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 937345824 for ; Fri, 24 Apr 2020 10:40:44 +0000 (UTC) X-FDA: 76742405208.13.desk07_7ae0e1bad7214 X-HE-Tag: desk07_7ae0e1bad7214 X-Filterd-Recvd-Size: 4361 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by imf37.hostedemail.com (Postfix) with ESMTP for ; Fri, 24 Apr 2020 10:40:44 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id k1so10217716wrx.4 for ; Fri, 24 Apr 2020 03:40:44 -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=6wACukIKb7o75IBFHY+ZsWVM/DZEQ0pO8PdBY9H3MtQ=; b=LDO3HwRZCsM9/FkdBzz6oNUwGT+t1xng7pUg62sM11nb8Ez2TA30Omqm9lRhs5AzZV jiEsZtfIKZ+BH6xGZknGJ0n64eWL6g4FwwToQdsAiASp1yvulv3lBcUBuxXzlixut3K3 XYohZAZ92Bqg1Jq+n3iIK/a0XXJ3cg+BzYh9ItcsHCrxuPJD7KPM/eHLTIA1pMhlqHsv ZgaDYS0ob9k2vPcZxW9EZ7Zy+/UDRkst3mBoXmuBpYvvC3J34kUNaWf9svNBIw9jpf3s 1UopMaD2cA/qJi+uVaEYLtLjuoJ54gtaWrCeVkcw0VUiG9TbzcFNwytPA5lX4k38Aok7 A1Kw== X-Gm-Message-State: AGi0PubKPlB9nNL62fSPVCy6Ba0LH1yxCku4yEavhw7PAYSx24yViBe8 61gx/80Nz+mKR3yXz0Hev6M= X-Google-Smtp-Source: APiQypI4kH4zJOTmKM6Tbsn9Z6WkxZM4yrZ1fOQ7gK83yr2LBeErj5QxTvDHH/I6XrOkgloNtjBlJg== X-Received: by 2002:a5d:6b85:: with SMTP id n5mr10504100wrx.370.1587724843192; Fri, 24 Apr 2020 03:40:43 -0700 (PDT) Received: from localhost (ip-37-188-130-62.eurotel.cz. [37.188.130.62]) by smtp.gmail.com with ESMTPSA id w11sm2208829wmi.32.2020.04.24.03.40.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Apr 2020 03:40:42 -0700 (PDT) Date: Fri, 24 Apr 2020 12:40:41 +0200 From: Michal Hocko To: Roman Gushchin Cc: Chris Down , Yafang Shao , akpm@linux-foundation.org, vdavydov.dev@gmail.com, linux-mm@kvack.org, stable@vger.kernel.org, hannes@cmpxchg.org Subject: Re: [PATCH] mm, memcg: fix wrong mem cgroup protection Message-ID: <20200424104041.GE11591@dhcp22.suse.cz> References: <20200423061629.24185-1-laoar.shao@gmail.com> <20200423153323.GA1318256@chrisdown.name> <20200423211319.GC83398@carbon.DHCP.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200423211319.GC83398@carbon.DHCP.thefacebook.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000162, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu 23-04-20 14:13:19, Roman Gushchin wrote: > On Thu, Apr 23, 2020 at 04:33:23PM +0100, Chris Down wrote: > > Hi Yafang, > > > > I'm afraid I'm just as confused as Michal was about the intent of this patch. > > > > Can you please be more concise and clear about the practical ramifications > > and demonstrate some pathological behaviour? I really can't visualise what's > > wrong here from your explanation, and if I can't understand it as the person > > who wrote this code, I am not surprised others are also confused :-) > > > > Or maybe Roman can try to explain, since he acked the previous patch? At > > least to me, the emin/elow behaviour seems fairly non-trivial to reason > > about right now. > > Hi Chris! > > So the thing is that emin/elow cached values are shared between global and > targeted (caused by memory.max) reclaim. It's racy by design, but in general > it should work ok, because in the end we'll reclaim or not approximately > the same amount of memory. > > In the case which Yafang described, the emin value calculated in the process > of the global reclaim leads to a slowdown of the targeted reclaim. It's not > a tragedy, but not perfect too. It seems that the proposed patch makes it better, > and as now I don't see any bad consequences. Do we have any means to quantify the effect? I do understand the racy nature of the effective protection values. We do update them in mem_cgroup_protected and that handles the reclaim_target == memcg case already. So why do we care later on in mem_cgroup_protection? And why don't we care about any other concurrent reclaimers which have a different reclaim memcg target? This just doesn't make any sense. Either we do care about races because they are harmful and then we care for all possible case or we don't and this patch doesn't really any big value. Or I still miss the point. -- Michal Hocko SUSE Labs