Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp1881955pxa; Mon, 3 Aug 2020 01:19:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwuAEbzYcxZ3y2u2UHQ8huj+okszqfQPGupKvtO0U8aWvbyh7LTXSgrW54c9Vxy1QLHg+OW X-Received: by 2002:a05:6402:2379:: with SMTP id a25mr14352209eda.180.1596442746330; Mon, 03 Aug 2020 01:19:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1596442746; cv=none; d=google.com; s=arc-20160816; b=TWkPJaK4KinLx3osI6qx44Z0Sbk2DRtpHD4zgeCmISR/vPsyV5f9mgTRe7Hajw5Hsc NO7CittGOPwCshjzAJsXi4wvRfZh/v3QXzLAYMxqprnYo4efqHB3Ea05qR68eQXPeoBx B33r2TvU6viwsn+yCIA9zO+WTq2g0EuvjHLyHcunbOTo4o6IUETOHhuWrOMWyqo3SdGJ aQhqIFgNwsDCkKeUU5crhbV3MQEs8GbpPqZKoUsQR1zrb4jqA8whYndXeb0HyppivQKO PuTynHS3MFfkaEoNZD4ne5HjoxKmQJ41G6203+rH2tqK4O9olTP0pXHmjLJsTYUvSKHv eLOA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=aS9rfgssnP7zc933dd1rd26tP9Q9uv5TFJLEmaQBDLE=; b=vuXtiPPfzO/A8yyT9Ar4YZ/abIRYLY0hDpF5itzJOAFwVUn2vvMmCMNFr5rXiPNruT b2cv+KXqgazdQa9uDM3t1oamqK1bUD6UKJEPwa4HSsDFwkigVEuy7Ja0jg6T/UI0e6+n Pk+rzKDyIdScTN2P5zxL0FjPdE2rCbR8SWOY2vDRhpy0PjT2c4EmJmgwm4ibMKs1Pfsh xw2gJiYA331L/px72TGJRepcjzPWSp+hSFbMF5Mvn8LapnNCuLZe3CQ10ZRDpQr+zju8 QUBR7itPDkwQLUG38trekhZxEmWAW1u7jaB+lXl8+2FEWbR2GxViRdzOmh2x3sPEuN7G JsWw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i1si10336986edn.445.2020.08.03.01.18.43; Mon, 03 Aug 2020 01:19:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725907AbgHCISR (ORCPT + 99 others); Mon, 3 Aug 2020 04:18:17 -0400 Received: from mx2.suse.de ([195.135.220.15]:38748 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725831AbgHCISR (ORCPT ); Mon, 3 Aug 2020 04:18:17 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id B499FABA2; Mon, 3 Aug 2020 08:18:30 +0000 (UTC) Date: Mon, 3 Aug 2020 10:18:15 +0200 From: Michal Hocko To: Alex Shi Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/memcg: remove useless check on page->mem_cgroup Message-ID: <20200803081815.GD5174@dhcp22.suse.cz> References: <1596166480-22814-1-git-send-email-alex.shi@linux.alibaba.com> <20200731151655.GB491801@cmpxchg.org> <9338716f-ca0e-057f-8d94-03e2b3f70281@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9338716f-ca0e-057f-8d94-03e2b3f70281@linux.alibaba.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat 01-08-20 11:58:41, Alex Shi wrote: > > > 在 2020/7/31 下午11:16, Johannes Weiner 写道: > >> if (!entry.val) { > >> memcg_memory_event(memcg, MEMCG_SWAP_FAIL); > > Uncharged readahead pages are gone, but I'm not 100% sure uncharged > > pages in general are gone. ISTR that the !page->mem_cgroup check in > > mem_cgroup_uncharge() prevented a crash - although that is of course a > > much broader interface, whereas the ones you change should only apply > > to LRU pages (which are hopefully all charged). > > > > Nevertheless, to avoid unnecessary crashes if we discover that we've > > been wrong, how about leaving the branches for now, but adding a (new) > > VM_WARN_ON_ONCE_PAGE() to them? Agreed! > Right, let's see if other unexcepted things happens, and then do actions. > So it's the patch: > > >From 28893cf8e55b98665cce58c0ba6d54aeafb63a62 Mon Sep 17 00:00:00 2001 > From: Alex Shi > Date: Sat, 1 Aug 2020 10:43:55 +0800 > Subject: [PATCH] mm/memcg: warning on !memcg after readahead page charged > > Since readahead page is charged on memcg too, in theory we don't have to > check this exception now. Before safely remove them all, add a warning > for the unexpected !memcg. I would find it useful to mention since when this assumption holds. > Signed-off-by: Alex Shi > Cc: Johannes Weiner > Cc: Michal Hocko > Cc: Vladimir Davydov > Cc: Andrew Morton > Cc: cgroups@vger.kernel.org > Cc: linux-mm@kvack.org > Cc: linux-kernel@vger.kernel.org > --- > include/linux/mmdebug.h | 8 ++++++++ > mm/memcontrol.c | 15 ++++++++------- > 2 files changed, 16 insertions(+), 7 deletions(-) > > diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h > index 2ad72d2c8cc5..639e98a3384e 100644 > --- a/include/linux/mmdebug.h > +++ b/include/linux/mmdebug.h > @@ -37,6 +37,13 @@ > BUG(); \ > } \ > } while (0) > +#define VM_WARN_ON_ONCE_PAGE(cond, page) \ > + do { \ > + if (unlikely(cond)) { \ > + dump_page(page, "VM_WARN_ON_ONCE_PAGE(" __stringify(cond)")");\ > + WARN_ON_ONCE(cond); \ > + } \ This is a bit strange behavior. You dump page for each occasion but warn only once. I would expect either "once" semantic for any output or just dump on each occasion because if the whole point is to reduce to amount of output then the above doesn't serve the purpose. -- Michal Hocko SUSE Labs