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.9 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,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 BB9B1C433DF for ; Thu, 21 May 2020 13:41:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 68494207F9 for ; Thu, 21 May 2020 13:41:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=chrisdown.name header.i=@chrisdown.name header.b="mVLBa0Yk" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 68494207F9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chrisdown.name Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id E598580008; Thu, 21 May 2020 09:41:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E0A6F80007; Thu, 21 May 2020 09:41:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CF94B80008; Thu, 21 May 2020 09:41:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0053.hostedemail.com [216.40.44.53]) by kanga.kvack.org (Postfix) with ESMTP id B5C4E80007 for ; Thu, 21 May 2020 09:41:50 -0400 (EDT) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 6B8EB180AD82F for ; Thu, 21 May 2020 13:41:50 +0000 (UTC) X-FDA: 76840839180.03.form47_4a3b96e870b1c X-HE-Tag: form47_4a3b96e870b1c X-Filterd-Recvd-Size: 4994 Received: from mail-ej1-f68.google.com (mail-ej1-f68.google.com [209.85.218.68]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Thu, 21 May 2020 13:41:50 +0000 (UTC) Received: by mail-ej1-f68.google.com with SMTP id x20so8818729ejb.11 for ; Thu, 21 May 2020 06:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chrisdown.name; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=xV51Tcrf9NcqZbm5wUPmCudngXiKCmzHzaVIGwxSLX0=; b=mVLBa0YkwB4qr/nGUx3mTqt/IBNkDYMevgIGIDvGXl6mMe9hC/iNBgUGd5KNQhW1C2 9VRaEeFAhHWBGnn62P2YYa9mMqk5yFn72KsrQrJt2qlo1uogjLnYcd8FWbScxgkMXJYD LjLNQZqXCO3CrKOtpR884DuapuK4oJipI1hO8= 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=xV51Tcrf9NcqZbm5wUPmCudngXiKCmzHzaVIGwxSLX0=; b=Lu8TIl1vLECDQChOEmWdyqzTELKveVsIYfB8SM0fcg7vaVFdBdz/zgK5sRODaOd2Pa Zcx0LWPCT6sH97J0YxAp1qArQKMEHafXeyuu1g89Jqd7btXDh8/eurhkyfcUmSv7Vg0W CeFsm7xeAGT+cFzmWAfzxUybwJY4ySvm3m9YH5o7bqT43zrBw6ovTW5OpD00GvieZzcm GCl4iW/lo3HncuBWRb/AV0PwoP3a8onFaN00Shs64jVLeg4FtJakY+0ZVIsja3VBsyq/ RCgU7ppIco9odkppfq7kBoUdE3LPOjvaJ73B8BGJY9PXfhXiUangVtSF/gnSrENQZ6E2 OhHQ== X-Gm-Message-State: AOAM532w2eG11lUAWm1K+gud/3w634C+jOhYkUoGjhrQ7zXEggIm+xAq mhD3TLwBVlJwfPG/obavlnrj7w== X-Google-Smtp-Source: ABdhPJyPmqgON7ZwGWSaHZxJk6nAVtW7JFpeftFSfh6aqvslRE6WSSH/itVmXPZpIv9jK/4agLflLg== X-Received: by 2002:a17:906:edd3:: with SMTP id sb19mr3469182ejb.39.1590068508871; Thu, 21 May 2020 06:41:48 -0700 (PDT) Received: from localhost ([2620:10d:c093:400::5:4262]) by smtp.gmail.com with ESMTPSA id f24sm4741685edq.21.2020.05.21.06.41.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 21 May 2020 06:41:48 -0700 (PDT) Date: Thu, 21 May 2020 14:41:47 +0100 From: Chris Down To: Michal Hocko 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: <20200521133324.GF990580@chrisdown.name> 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> <20200521132120.GR6462@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20200521132120.GR6462@dhcp22.suse.cz> 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: Michal Hocko writes: >On Thu 21-05-20 13:57:59, Chris Down wrote: >> Michal Hocko writes: >> > > A cgroup is a unit and breaking it down into "reclaim fairness" for >> > > individual tasks like this seems suspect to me. For example, if one task in >> > > a cgroup is leaking unreclaimable memory like crazy, everyone in that cgroup >> > > is going to be penalised by allocator throttling as a result, even if they >> > > aren't "responsible" for that reclaim. >> > >> > You are right, but that doesn't mean that it is desirable that some >> > tasks would be throttled unexpectedly too long because of the other's activity. >> >> Are you really talking about throttling, or reclaim? If throttling, tasks >> are already throttled proportionally to how much this allocation is >> contributing to the overage in calculate_high_delay. > >Reclaim is a part of the throttling mechanism. It is a productive side >of it actually. I guess let's avoid using the term "throttling", since in this context it sounds like we're talking about allocator throttling :-) >> 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.