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 C8589C433E0 for ; Thu, 21 May 2020 13:58:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 8B9C820748 for ; Thu, 21 May 2020 13:58:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B9C820748 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 26BDC80008; Thu, 21 May 2020 09:58:43 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 21CA980007; Thu, 21 May 2020 09:58:43 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10C3080008; Thu, 21 May 2020 09:58:43 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id EA03180007 for ; Thu, 21 May 2020 09:58:42 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id A470D513 for ; Thu, 21 May 2020 13:58:42 +0000 (UTC) X-FDA: 76840881684.08.land82_4bff79d875a16 X-HE-Tag: land82_4bff79d875a16 X-Filterd-Recvd-Size: 4387 Received: from mail-ej1-f67.google.com (mail-ej1-f67.google.com [209.85.218.67]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Thu, 21 May 2020 13:58:42 +0000 (UTC) Received: by mail-ej1-f67.google.com with SMTP id d7so8925477eja.7 for ; Thu, 21 May 2020 06:58:42 -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=ddLwWOZufRU83kRzWZ3D0JojQ9PBPAMnKhIGdw1eqxU=; b=Y0PYvEZ0ZrDsX6RWYJQIRoIbeCMZ6Dq7kRDUFNg08mhjs5NpU4GIQFFIaDN309D5nr /gKCg2wfx6/tNeNExXXBRJkP17TUgKytg3zILUfxpGk4dB+5tqSxyC4ecXSK5t6oAT2K r7krhwjqpUVHw6Yj8puYb20r1FO5JWzHaAFSt/OZkCrR/xclvdmoyk2/pBLW9xxNetLo bkCKFROe8ubDjQ2V8B+1QUTgrxvDiSB2IeePtndelj238mHpoyDuPWUx0FjkYtMkaxYu qhFvHNHzti8DBJ6TURS2aWJqcrw2UW8Us5pWV7Gv5O1YOIAl052KqGSNvXsVVIKNwgEH i5Ew== X-Gm-Message-State: AOAM5334yCcm3V4cenxzywqko41XFiM8w5fAczlKuSbpxdh8md7tA6dA 48qHULF76yNned4UP0KuucU= X-Google-Smtp-Source: ABdhPJzPRBFDa0mlq1OwZfH77wBLvsLKgpZD9t/9lF1bGNYWZapDHrzDtDAUg1eAZDj0WFY3c0IPrg== X-Received: by 2002:a17:906:6951:: with SMTP id c17mr3607034ejs.112.1590069521064; Thu, 21 May 2020 06:58:41 -0700 (PDT) Received: from localhost (ip-37-188-180-112.eurotel.cz. [37.188.180.112]) by smtp.gmail.com with ESMTPSA id c7sm4755917edj.54.2020.05.21.06.58.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2020 06:58:40 -0700 (PDT) Date: Thu, 21 May 2020 15:58:38 +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: <20200521135838.GT6462@dhcp22.suse.cz> References: <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> <20200521132120.GR6462@dhcp22.suse.cz> <20200521133324.GF990580@chrisdown.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200521133324.GF990580@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:41:47, Chris Down wrote: > Michal Hocko writes: > > On Thu 21-05-20 13:57:59, Chris Down wrote: [...] > > > If you're talking about reclaim, trying to reason about whether the overage > > > is the result of some other task in this cgroup or the task that's > > > allocating right now is something that we already know doesn't work well > > > (eg. global OOM). > > > > I am not sure I follow you here. > > Let me rephrase: your statement is that it's not desirable "that some task > would be throttled unexpectedly too long because of [the activity of another > task also within that cgroup]" (let me know if that's not what you meant). > But trying to avoid that requires knowing which activity abstractly > instigates this entire mess in the first place, which we have nowhere near > enough context to determine. Yeah, if we want to be really precise then you are right, nothing like that is really feasible for the reclaim. Reclaiming 1 page might be much more expensive than 100 pages because LRU order doesn't reflect the cost of the reclaim at all. What, I believe, we want is a best effort, really. If the reclaim target is somehow bound to the requested amount of memory then we can at least say that more memory hungry consumers are reclaiming more. Which is something people can wrap their head around much easier than a free competition on the reclaim with some hard to predict losers who do all the work and some lucky ones which just happen to avoid throttling by a better timing. Really think of the direct reclaim and how the unfairness suck there. -- Michal Hocko SUSE Labs