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.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, 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 0F3BEC433E0 for ; Thu, 28 May 2020 20:11:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BDFDA207D3 for ; Thu, 28 May 2020 20:11:47 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cmpxchg-org.20150623.gappssmtp.com header.i=@cmpxchg-org.20150623.gappssmtp.com header.b="OgFfHLjM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BDFDA207D3 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cmpxchg.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 656A18001A; Thu, 28 May 2020 16:11:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 62DF580010; Thu, 28 May 2020 16:11:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4F6308001A; Thu, 28 May 2020 16:11:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) by kanga.kvack.org (Postfix) with ESMTP id 37CA580010 for ; Thu, 28 May 2020 16:11:47 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id E40E68245571 for ; Thu, 28 May 2020 20:11:46 +0000 (UTC) X-FDA: 76867223412.16.crown36_66c49032c3101 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin16.hostedemail.com (Postfix) with ESMTP id C2332100FE21F for ; Thu, 28 May 2020 20:11:46 +0000 (UTC) X-HE-Tag: crown36_66c49032c3101 X-Filterd-Recvd-Size: 6035 Received: from mail-qv1-f68.google.com (mail-qv1-f68.google.com [209.85.219.68]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Thu, 28 May 2020 20:11:46 +0000 (UTC) Received: by mail-qv1-f68.google.com with SMTP id l3so13577950qvo.7 for ; Thu, 28 May 2020 13:11:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=83zLTVKdvpR2KxKh88qE1mTweOG1k93RYAEKbnweuYU=; b=OgFfHLjM0xzOmXUQpzcCAMMrfpbK7MxIECNfhMYFKDunkqaArhuEzxRhhBna2RhZWt dI5uXxPB91bBATybc4BO6D/IZ9XFYihdh4Ww2J/zjZAOcfJs0Ywxe5XpkYtsbPVHcnN+ dQNWfQWnFUJqwapSBddU8wJ3Jf+P0hmGbx79Gxlz8Mz4JxS/hOUQnsrgbwoTF/C2J9CY +ldcrCBHzBD9/d/fM7E+irtE/rIfpQJ/awZqWcpJtHj+TuXt7Gelc9gpi1v4YwSvup+R R95gCm5EwJnymHuv8GMnue0qTo/SUO2lAO0OvH4i1mBJbpu5cvs8jyDX5m3VeVsb1HgI xeXg== 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=83zLTVKdvpR2KxKh88qE1mTweOG1k93RYAEKbnweuYU=; b=WavMwg6FxmOOSFyYo3JViXco3pjUUwTgJJ8Hwq3a/2p93ZewtuJGcZr++Vyz+9bA94 vMXTqVqqISf5Hd5i28gR7xNeA52jMPDXYQ40qvEturXsn6eRAjWjRB1ODA28V9NmQt3n rCjRhNK6qmq44mmiW3CJ3Q8IaEUETyMedRwSVrq58CCF6ULfLXIOK9yLdsUQAHPItBgg dUCvyCHrs+o1syoy9lS5AuW4kXbuDgFJ+azOlhAMuXp0/fo3pweEI07wJoWZYeRk3OKE ttSlDi5sovgb27WSpqegwbNt8L/9V5HbS1twh3ulpzLARmQEs01Jfnh2e/ScZe+CfSbj oVrA== X-Gm-Message-State: AOAM530rablUs755AV96/qr1vlKyAaz7HL8M+AjixUk064fDFcBxICxn cODQ2zg7tQ05/5jAeSznVR/oZ930+S0= X-Google-Smtp-Source: ABdhPJwVzQ41nOq3YlszafKQOCiQXl6KehufAtMo9uhqbuy6HXJ3L5Rb6re1G77IVPDUCvMjAIhTgA== X-Received: by 2002:a0c:a9c6:: with SMTP id c6mr4986010qvb.224.1590696705375; Thu, 28 May 2020 13:11:45 -0700 (PDT) Received: from localhost ([2620:10d:c091:480::1:2535]) by smtp.gmail.com with ESMTPSA id v2sm5889705qtq.8.2020.05.28.13.11.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2020 13:11:44 -0700 (PDT) Date: Thu, 28 May 2020 16:11:17 -0400 From: Johannes Weiner To: Michal Hocko Cc: Chris Down , Andrew Morton , Tejun Heo , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH] mm, memcg: reclaim more aggressively before high allocator throttling Message-ID: <20200528201117.GD69521@cmpxchg.org> References: <20200520165131.GB630613@cmpxchg.org> <20200520170430.GG6462@dhcp22.suse.cz> <20200520175135.GA793901@cmpxchg.org> <20200521073245.GI6462@dhcp22.suse.cz> <20200521135152.GA810429@cmpxchg.org> <20200521143515.GU6462@dhcp22.suse.cz> <20200521163833.GA813446@cmpxchg.org> <20200521173701.GX6462@dhcp22.suse.cz> <20200521184505.GA815980@cmpxchg.org> <20200528163101.GJ27484@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200528163101.GJ27484@dhcp22.suse.cz> X-Rspamd-Queue-Id: C2332100FE21F X-Spamd-Result: default: False [0.00 / 100.00] X-Rspamd-Server: rspam04 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 Thu, May 28, 2020 at 06:31:01PM +0200, Michal Hocko wrote: > On Thu 21-05-20 14:45:05, Johannes Weiner wrote: > > After analyzing this problem, it's clear that we had an oversight > > here: all other reclaimers are already familiar with the fact that > > reclaim may not be able to complete the reclaim target in one call, or > > that page reclaim is inherently racy and reclaim work can be stolen. > > There is no disagreement here. > > > We send a simple bug fix: bring this instance of reclaim in line with > > how everybody else is using the reclaim API, to meet the semantics as > > they are intendend and documented. > > Here is where we are not on the same page though. Once you have identified > that the main problem is that the reclaim fails too early to meet the > target then the fix would be to enforce that target. I have asked why > this hasn't been done and haven't got any real answer for that. Then I encourage you to re-read the thread. I have explained that reclaim invocations can fail to meet the requested target for a variety of reasons, including dirty state or other states that make memory temporarily unreclaimable, race conditions between reclaimers and so forth. I have also pointed out that this is widely acknowledged by the fact that all other reclaimers retry in the exact same manner. If you want to question that VM-wide precedence, please do so in your own patches. As to the question around fairness, I have explained that fairness is a best effort and that if push comes to shove, preventing premature OOM situations or failing cgroup containment and causing system-wide OOMs is more important. > Instead what you call "a simple bug fix" has larger consequences > which are not really explained in the changelog and they are also > not really trivial to see. If the changelog explicitly stated that > the proportional memory reclaim is not sufficient because XYZ and > the implementation has been changed to instead meet the high limit > target then this would be a completely different story and I believe > we could have saved some discussion. The point of memory.high reclaim is to meet the memory.high memory limit. That, too, has been addressed - although it's astounding that it needed to be pointed out. The proportionality is an attempt at fairness that doesn't override the primary purpose. I appreciate your concerns, but your questions have been addressed. And you're not contributing anything of value to the conversation until you familiarize yourself with the purpose of the memory.high interface. Thanks