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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 AD72EC433B4 for ; Thu, 8 Apr 2021 15:08:20 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3DA97610D1 for ; Thu, 8 Apr 2021 15:08:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3DA97610D1 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CA3F66B0080; Thu, 8 Apr 2021 11:08:19 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C7B0F8D0002; Thu, 8 Apr 2021 11:08:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B1DFF6B0082; Thu, 8 Apr 2021 11:08:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0181.hostedemail.com [216.40.44.181]) by kanga.kvack.org (Postfix) with ESMTP id 9A30C6B0080 for ; Thu, 8 Apr 2021 11:08:19 -0400 (EDT) Received: from smtpin37.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 523CD9413 for ; Thu, 8 Apr 2021 15:08:19 +0000 (UTC) X-FDA: 78009530718.37.B9EB068 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf26.hostedemail.com (Postfix) with ESMTP id E04C640002D0 for ; Thu, 8 Apr 2021 15:08:15 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1617894497; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TBg+itYPsPJsb2/umgmP6I2xkGrOVNCioeyRXHmIdOY=; b=O8W4MqEeWnmVa6Kg1nm/gJoBcA8QGilvgWn3bIGb4Q8L9/7qESs2dy/HF4iHN1xRtN0Xc4 2KrxwgdvGq16B5PafIB2k9geb3RyU3yf/5vzQKKLeMJLsZ/NIHhL8jdDS734ufodBRGDyj wwDgqmyTdmbfa0pCQHgkG49cK7Ruf9I= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 4519AB148; Thu, 8 Apr 2021 15:08:17 +0000 (UTC) Date: Thu, 8 Apr 2021 17:08:16 +0200 From: Michal Hocko To: Johannes Weiner Cc: Andrew Morton , Hugh Dickins , Shakeel Butt , Roman Gushchin , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH] mm: page_counter: mitigate consequences of a page_counter underflow Message-ID: References: <20210408143155.2679744-1-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210408143155.2679744-1-hannes@cmpxchg.org> X-Rspamd-Queue-Id: E04C640002D0 X-Stat-Signature: ijugeihidm8p8u6zbiceiz3i1o1b81jx X-Rspamd-Server: rspam02 Received-SPF: none (suse.com>: No applicable sender policy available) receiver=imf26; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617894495-409054 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 08-04-21 10:31:55, Johannes Weiner wrote: > When the unsigned page_counter underflows, even just by a few pages, a > cgroup will not be able to run anything afterwards and trigger the OOM > killer in a loop. > > Underflows shouldn't happen, but when they do in practice, we may just > be off by a small amount that doesn't interfere with the normal > operation - consequences don't need to be that dire. Yes, I do agree. > Reset the page_counter to 0 upon underflow. We'll issue a warning that > the accounting will be off and then try to keep limping along. I do not remember any reports about the existing WARN_ON but it is not really hard to imagine a charging imbalance to be introduced easily. > [ We used to do this with the original res_counter, where it was a > more straight-forward correction inside the spinlock section. I > didn't carry it forward into the lockless page counters for > simplicity, but it turns out this is quite useful in practice. ] The lack of external synchronization makes it more tricky because certain charges might get just lost depending on the ordering. This sucks but considering that the system is already botched and counters cannot be trusted this is definitely better than a potentially completely unusable memcg. It would be nice to mention that in the above paragraph as a caveat. > Signed-off-by: Johannes Weiner Acked-by: Michal Hocko > --- > mm/page_counter.c | 8 ++++++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/mm/page_counter.c b/mm/page_counter.c > index c6860f51b6c6..7d83641eb86b 100644 > --- a/mm/page_counter.c > +++ b/mm/page_counter.c > @@ -52,9 +52,13 @@ void page_counter_cancel(struct page_counter *counter, unsigned long nr_pages) > long new; > > new = atomic_long_sub_return(nr_pages, &counter->usage); > - propagate_protected_usage(counter, new); > /* More uncharges than charges? */ > - WARN_ON_ONCE(new < 0); > + if (WARN_ONCE(new < 0, "page_counter underflow: %ld nr_pages=%lu\n", > + new, nr_pages)) { > + new = 0; > + atomic_long_set(&counter->usage, new); > + } > + propagate_protected_usage(counter, new); > } > > /** > -- > 2.31.1 -- Michal Hocko SUSE Labs