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 9D00DC433E0 for ; Thu, 21 May 2020 12:28:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 566A72070A for ; Thu, 21 May 2020 12:28:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 566A72070A 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 D8C0280008; Thu, 21 May 2020 08:28:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D496180007; Thu, 21 May 2020 08:28:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C293580008; Thu, 21 May 2020 08:28:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0231.hostedemail.com [216.40.44.231]) by kanga.kvack.org (Postfix) with ESMTP id A94B580007 for ; Thu, 21 May 2020 08:28:19 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 6F9D6181AEF23 for ; Thu, 21 May 2020 12:28:19 +0000 (UTC) X-FDA: 76840653918.14.pen03_e6d56c447229 X-HE-Tag: pen03_e6d56c447229 X-Filterd-Recvd-Size: 3535 Received: from mail-ej1-f67.google.com (mail-ej1-f67.google.com [209.85.218.67]) by imf14.hostedemail.com (Postfix) with ESMTP for ; Thu, 21 May 2020 12:28:19 +0000 (UTC) Received: by mail-ej1-f67.google.com with SMTP id z5so8607297ejb.3 for ; Thu, 21 May 2020 05:28:18 -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=x7HgeO9Wvnx9mP+TZwfptn5IG/xaG2iUlETmitshdYQ=; b=ZO3VuxlGYttACmpU6mXQJ7eXVoOcet5NBzHAFqlmNRXgf9lr/M5jGnHPzfHqK31PMR mdnmxFHYK3ggbpEg0NZ2tKxgcQdHCYBPwjM7Om+TzHXlquKoJPlZ6O9/3W+JQ2A9FZTV VVZhgYTH9Ep88CIrfVnCbSFaYPLSKTCI0HNLdPdKxTA4Q5z+Lg2tSOCfF21N3T1+SJKD 9RgkG6Bib8v9M3GXc+KODYEWAuRqA929kion3fF0mq5t8A+648dr5gtN3EQIRCgRfgsH EV/lDEk3QydUEl2WS1ymchED6DkhLZa/BntgdUnm4e/Fd9IJFlTUGgr+YmEyJa5hrr7N ueKg== X-Gm-Message-State: AOAM533Qhnqfl9jAW8g4p7aZpmj24P+GUbjY+KetnecT6aaHMlquoER5 6AHxrhOnO/2rZIQH9NhWpoM= X-Google-Smtp-Source: ABdhPJwU1TxI7Iw7jPzJ9tumWfRUHFAImd6A3+apajoIYs4m83HPBzUZydLFJUQoC7dh0hPotkQ/eA== X-Received: by 2002:a17:906:1c94:: with SMTP id g20mr3176649ejh.319.1590064098014; Thu, 21 May 2020 05:28:18 -0700 (PDT) Received: from localhost (ip-37-188-180-112.eurotel.cz. [37.188.180.112]) by smtp.gmail.com with ESMTPSA id bz8sm4610805ejc.94.2020.05.21.05.28.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2020 05:28:16 -0700 (PDT) Date: Thu, 21 May 2020 14:28:14 +0200 From: Michal Hocko To: Chris Down Cc: Andrew Morton , Johannes Weiner , 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: <20200521122814.GN6462@dhcp22.suse.cz> References: <20200520143712.GA749486@chrisdown.name> <20200520160756.GE6462@dhcp22.suse.cz> <20200520202650.GB558281@chrisdown.name> <20200521071929.GH6462@dhcp22.suse.cz> <20200521112711.GA990580@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200521112711.GA990580@chrisdown.name> 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 21-05-20 12:27:11, Chris Down wrote: [...] > Regardless, you're pushing for different reclaim semantics for memory.high > than memory.max here, which requires evidence that the current approach > taken for memory.max is wrong or causing issues. Sorry, I have skipped over this part. Memory high limit reclaim has historically acted as a best effort action to throttle the allocation/charge pace. This would work both if the implementation simply tried to reclaim down to the high limit or if the reclaim is proportional to the memory consumption by a specific consumer. We do the later because it is much easier to establish fairness for. If you want to change that you somehow have to deal with the fairness problem. And yes, we do not guarantee any fairness for the hard limit or direct reclaim in general but that behavior is generally problematic and there should be really strong arguments to move high limit reclaim that direction IMHO. -- Michal Hocko SUSE Labs