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 DADA9C433DF for ; Thu, 21 May 2020 13:28:31 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9A567206BE for ; Thu, 21 May 2020 13:28:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9A567206BE 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 3895A80008; Thu, 21 May 2020 09:28:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3133580007; Thu, 21 May 2020 09:28:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1DA4880008; Thu, 21 May 2020 09:28:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0102.hostedemail.com [216.40.44.102]) by kanga.kvack.org (Postfix) with ESMTP id 019C080007 for ; Thu, 21 May 2020 09:28:30 -0400 (EDT) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id AE7562C2A for ; Thu, 21 May 2020 13:28:30 +0000 (UTC) X-FDA: 76840805580.10.judge21_675f5f33da054 X-HE-Tag: judge21_675f5f33da054 X-Filterd-Recvd-Size: 5235 Received: from mail-ej1-f67.google.com (mail-ej1-f67.google.com [209.85.218.67]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Thu, 21 May 2020 13:28:30 +0000 (UTC) Received: by mail-ej1-f67.google.com with SMTP id l21so8820347eji.4 for ; Thu, 21 May 2020 06:28:30 -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=jDCx2WxHF0tPV5ThYACQPXq1Ci/r8leV3iJmKPX73kw=; b=NoYUtdltI4zEsku8GcGy97UpL+ciFF5WYK5jY4zJcuNYp90TxwXYqNKq6pHdu51pnx QmWJtS1JT6eh5A9R3hqireggmDupbPx9/kyG8Jrv+oQqsdM3eR3LtO7LgyPcerQXp+G9 MNIVjc9vl6YEvVJOx1IuVNquOdHZlhEAWhEW/nSH2I2Q+CqNWe0EN0PZIdcvk8bP7Izn CVu5cuklKJX0DVuPvIKyJPnUIogOHhU8hJb+6Zyyo42JRPpKrhmHrTdnx0zhTVvQSWEL zsqniN7LUwltslRlFzO79ZN8al+3hdibGpJdXACgl8sI2jXkKK9R6aEdEWIOxmPs3x+E KJcg== X-Gm-Message-State: AOAM5332DrDd9lFOBjSJ+DBv6SRAHCLMNO+tGmSXhiqUmTs6X8CQxJOX WR1t+DyqCLpU+v2jL13h1L0= X-Google-Smtp-Source: ABdhPJxcg8Jgr6GoENH6kS+Ld5vOWysHqjKl+LyRLD/wTM/EcTsTUQWzPImWfcXO0JDudNQbEEsQ/Q== X-Received: by 2002:a17:906:278e:: with SMTP id j14mr3487532ejc.270.1590067709162; Thu, 21 May 2020 06:28:29 -0700 (PDT) Received: from localhost (ip-37-188-180-112.eurotel.cz. [37.188.180.112]) by smtp.gmail.com with ESMTPSA id bi7sm4745696edb.17.2020.05.21.06.28.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2020 06:28:27 -0700 (PDT) Date: Thu, 21 May 2020 15:28:26 +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: <20200521132826.GS6462@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> <20200521120455.GM6462@dhcp22.suse.cz> <20200521122327.GB990580@chrisdown.name> <20200521123742.GO6462@dhcp22.suse.cz> <20200521125759.GD990580@chrisdown.name> <20200521130530.GE990580@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200521130530.GE990580@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 14:05:30, Chris Down wrote: > Chris Down writes: > > > I believe I have asked in other email in this thread. Could you explain > > > why enforcint the requested target (memcg_nr_pages_over_high) is > > > insufficient for the problem you are dealing with? Because that would > > > make sense for large targets to me while it would keep relatively > > > reasonable semantic of the throttling - aka proportional to the memory > > > demand rather than the excess. > > > > memcg_nr_pages_over_high is related to the charge size. As such, if > > you're way over memory.high as a result of transient reclaim failures, > > but the majority of your charges are small, it's going to hard to make > > meaningful progress: > > > > 1. Most nr_pages will be MEMCG_CHARGE_BATCH, which is not enough to help; > > 2. Large allocations will only get a single reclaim attempt to succeed. > > > > As such, in many cases we're either doomed to successfully reclaim a > > paltry amount of pages, or fail to reclaim a lot of pages. Asking > > try_to_free_pages() to deal with those huge allocations is generally not > > reasonable, regardless of the specifics of why it doesn't work in this > > case. > > Oh, I somehow elided the "enforcing" part of your proposal. Still, there's > no guarantee even if large allocations are reclaimed fully that we will end > up going back below memory.high, because even a single other large > allocation which fails to reclaim can knock us out of whack again. Yeah, there is no guarantee and that is fine. Because memory.high is not about guarantee. It is about a best effort and slowing down the allocation pace so that the userspace has time to do something about that. That being said I would be really curious about how enforcing the memcg_nr_pages_over_high target works in your setups where you see the problem. If that doesn't work for some reason and the reclaim should be more pro-active then I would suggest to scale it via memcg_nr_pages_over_high rather than essentially keep it around and ignore it. Preserving at least some form of fairness and predictable behavior is important IMHO but if there is no way to achieve that then there should be a very good explanation for that. I hope that we it is more clear what is our thinking now. I will be FTO for upcoming days trying to get some rest from email so my response time will be longer. Will be back on Thursday. -- Michal Hocko SUSE Labs