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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id ADCADC433F5 for ; Wed, 16 Feb 2022 13:12:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 356A96B0071; Wed, 16 Feb 2022 08:12:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2DDDC6B0073; Wed, 16 Feb 2022 08:12:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 159386B0074; Wed, 16 Feb 2022 08:12:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0135.hostedemail.com [216.40.44.135]) by kanga.kvack.org (Postfix) with ESMTP id 051B36B0071 for ; Wed, 16 Feb 2022 08:12:37 -0500 (EST) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 94FDB180972D2 for ; Wed, 16 Feb 2022 13:12:36 +0000 (UTC) X-FDA: 79148682312.28.E2EFC8B Received: from mail-ed1-f54.google.com (mail-ed1-f54.google.com [209.85.208.54]) by imf01.hostedemail.com (Postfix) with ESMTP id 316CC40003 for ; Wed, 16 Feb 2022 13:12:36 +0000 (UTC) Received: by mail-ed1-f54.google.com with SMTP id i11so2195841eda.9 for ; Wed, 16 Feb 2022 05:12:35 -0800 (PST) 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:user-agent; bh=m421YRZGEJntA1XH4znYoSO6mB7oCx7u3N2gxq1kXl8=; b=aOXX1rJua9aTg8AxXa9i5j/RrNeJ8pxuXHF6ZRAFhiRvpVqHcKu6sdF8v3yuqEvhZz dfuCOtY2syT4cnOPJ03kMrqcmIXW+VpNH5kcwGYC0m0PKGxdCthSHpXwTqbzkxAGfREd Ox9zBsQGMJZdE/5KrTAyqzsm2d6gLjY19hn2g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=m421YRZGEJntA1XH4znYoSO6mB7oCx7u3N2gxq1kXl8=; b=038vI1vSEzzdytik00c3nl84p3s0QC5ALFCyrGtBNmskpAyAqsp7aX+x0M6xIhi8gc OoN/KgIO/zk2yAZFkltP81+U/Y7rQS46l12hB9EjJTMVvhAnbLTF4AnVy0DdwCLBbRWx TkjMtF5Lux0LTEtgrLwDLBzGFJ4rsvTVCWTyRbR8gjfPrJKKkREndNhASxZqqfdwArWA uGHBK/Ric6Cv0+z6VhiASz+w4dzqH/pMZT84+Y2ky5USO9XtOJMwln+oYKEOEjQ6RCwF aoAsphsKhXX1Mdku2ZD25psVCgv//FKyhWz/Mn2UzQNzC4WX4QgBHlpjevy44Bi0cPyp WLIg== X-Gm-Message-State: AOAM5328eVyJxZY6axUp3Q4PslWrHYguiHx0EU75unkblJ4SyzQBLgGS mGe7pfNL0FWK8A39ZqPBla7oZw== X-Google-Smtp-Source: ABdhPJy4+BOqL1A5ydec/gIJxjR2gGyCphXlGTfzjc+DNWQTHybHfqoIr+VeBuTkK4KODG+Bv1ICWA== X-Received: by 2002:a05:6402:268c:b0:411:e086:b7d1 with SMTP id w12-20020a056402268c00b00411e086b7d1mr2797303edd.111.1645017154635; Wed, 16 Feb 2022 05:12:34 -0800 (PST) Received: from localhost ([2620:10d:c093:400::5:279b]) by smtp.gmail.com with ESMTPSA id t26sm745556edv.50.2022.02.16.05.12.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Feb 2022 05:12:34 -0800 (PST) Date: Wed, 16 Feb 2022 13:12:33 +0000 From: Chris Down To: Shakeel Butt Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Andrew Morton , Cgroups , Linux MM , LKML Subject: Re: [PATCH v2 4/4] memcg: synchronously enforce memory.high for large overcharges Message-ID: References: <20220211064917.2028469-1-shakeelb@google.com> <20220211064917.2028469-5-shakeelb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2 (7160e05a) (2022-02-12) X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 316CC40003 X-Stat-Signature: iyetjqpndbjeaxsn5zuquy5s444uhfrn X-Rspam-User: Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=chrisdown.name header.s=google header.b=aOXX1rJu; dmarc=pass (policy=none) header.from=chrisdown.name; spf=pass (imf01.hostedemail.com: domain of chris@chrisdown.name designates 209.85.208.54 as permitted sender) smtp.mailfrom=chris@chrisdown.name X-HE-Tag: 1645017156-10871 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: Shakeel Butt writes: >> Thanks, I was going to comment on v1 that I prefer to keep the implementation >> of mem_cgroup_handle_over_high if possible since we know that the mechanism has >> been safe in production over the past few years. >> >> One question I have is about throttling. It looks like this new >> mem_cgroup_handle_over_high callsite may mean that throttling is invoked more >> than once on a misbehaving workload that's failing to reclaim since the >> throttling could be invoked both here and in return to userspace, right? That >> might not be a problem, but we should think about the implications of that, >> especially in relation to MEMCG_MAX_HIGH_DELAY_JIFFIES. >> > >Please note that mem_cgroup_handle_over_high() clears >memcg_nr_pages_over_high and if on the return-to-userspace path >mem_cgroup_handle_over_high() finds that memcg_nr_pages_over_high is >non-zero, then it means the task has further accumulated the charges >over high limit after a possibly synchronous >memcg_nr_pages_over_high() call. Oh sure, my point was only that MEMCG_MAX_HIGH_DELAY_JIFFIES was to more reliably ensure we are returning to userspace at some point in the near future to allow the task to have another chance at good behaviour instead of being immediately whacked with whatever is monitoring PSI -- for example, in the case where we have a daemon which is monitoring its own PSI contributions and will make a proactive attempt to free structures in userspace. That said, the throttling here still isn't unbounded, and it's not likely that anyone doing such large allocations after already exceeding memory.high is being a good citizen, so I think the patch makes sense as long as the change is understood and documented internally. Thanks! Acked-by: Chris Down