Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1440522pxb; Wed, 10 Feb 2021 08:24:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJxcid/Wzn6EWYDOMCMStyc6es168DLXY2eiXHMqLDj7dpmXdIt/OprYThiqeM8o/v6QLELB X-Received: by 2002:a05:6402:27cf:: with SMTP id c15mr3800389ede.179.1612974246955; Wed, 10 Feb 2021 08:24:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612974246; cv=none; d=google.com; s=arc-20160816; b=B68VkcK+UIppkXCCl6L8bw9OU0Lb4LHNTyzKcO4k4MAFv1JLR3/9YizVvHoCEUZP8Z wngvOSwSztEvHk2JC/zdOt5EKLzWJAxRiMCof+E4inZ7L/dggl4ZRRSPpWwo6LhN2FJF j+7MQs2ZfsmOK6dW/g5hRfNx3U39fyuJAq2JYpPa9WMENnIwT7XlQHOMeg22GOvqIGTi RCILXMy+ij89EaQztismNMNI9/JwaHCeOYFUpfDYpVRlhIu5a3EEIRydOy2BOdX0uvmw JizSawPDj5g9sJ+QiUbLK2UVx2/U/IaNYn9H6VVV9ulsczPrwsqTQa/WXGm2pul+wcYt jJkQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent:references:message-id :in-reply-to:subject:cc:to:from:date:dkim-signature; bh=wc8HtUu6YXXorPykhuoj08SCrBEaocuYohr96nbgn+w=; b=X6rxOUsHseq129CZFq18H9iDafkBLK347onXx2pVbEsABXmZBcafDtl4MvEdzReo5G GJ8yvfzz3K1IgvotSARMwxkw/UmCUoYA9Lj/G/bQVZ/7PobeyzZPLOI2/KYVkn+DzYXF zPDY2Eewt/Pne/SNGBWBQVKAx7tOdKkL/zlPa9KRV1fpYE2UmoKvJgAn8Lx9nKpEbLcH TyeIMp9UOueyfyBIu1tufId/OyZf5xLDxGRJOTYaoA7Tt9jOXDSChWIeQOdyhnBEKzPu kJAuDklDwkh/YJaXFypEAk9edZTvCIhPKu26Bq4TizDft2iOuC/pBKheYJtGfmCv+83Q DPYQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=fpSdWoUW; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x5si1542057ejv.626.2021.02.10.08.23.43; Wed, 10 Feb 2021 08:24:06 -0800 (PST) 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; dkim=pass header.i=@google.com header.s=20161025 header.b=fpSdWoUW; 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; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232270AbhBJQXC (ORCPT + 99 others); Wed, 10 Feb 2021 11:23:02 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231983AbhBJQW7 (ORCPT ); Wed, 10 Feb 2021 11:22:59 -0500 Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3E287C06174A for ; Wed, 10 Feb 2021 08:22:19 -0800 (PST) Received: by mail-ot1-x32c.google.com with SMTP id l23so2285081otn.10 for ; Wed, 10 Feb 2021 08:22:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=wc8HtUu6YXXorPykhuoj08SCrBEaocuYohr96nbgn+w=; b=fpSdWoUW/YxqsP5HrQVPzNsTdbTt5mOIk6GqFhMMF/biAw553DP/Q7qeQJMjwPShNk 1tRCVOShdBPkTNGrIargdgle8wgQceXqCAn3IHA7g3D04Ow8R7+9FWnFmuNmYkLtRhc3 NPZRlQhxOcWweh5MO8A8cXXzWeWCBg+WAxOyFchaYUnrwwxZ4crSYQ0oL8jAS9UrwmfP CW1W7cC6X2NLISJ0M4LetFXkBGcA78Y68b1khrpiqAvP7GG9vuz60hI/o+GaUIpyObsJ SJ7LZjvLn5dEu4MAlTKTFOVnNmu8Z9Fsn7GavQTkW21qdobIJyuLdv3dBLsT3lnHDn9s ymow== 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:in-reply-to:message-id :references:user-agent:mime-version; bh=wc8HtUu6YXXorPykhuoj08SCrBEaocuYohr96nbgn+w=; b=rBv1vjexs/3sehbiTsD/I2F+sS4Bc74ZaAEhm+OUCubMohOUuXuYU3juuUWVMHzskh 510ssYQ5qEcYws9Ya3MEfgIavQmDwSlzVzQCCHDYxNFHmRREJTeOgIXM2VJgsQDZPtxw V9ux1CO6rSdRtMiZpMdIuGrvjRoHl+wH/6KmiR0tOCj+fq4NBrPXxGuDp6t5Cn909+5Z QdTrWt7yuSvDhdIKfEB2lYcppZ3TyPH0l5XrQ+81pNZcANH3eG/eHAjcNbwz3C5bCXDe f+ux+CLOpIia9knSw+cBcEgcIIuPuts3tQTtUJO85CVz61Cw++gjd1RB4A5K/i7Bp+Pt CXGA== X-Gm-Message-State: AOAM530/P6/JUw1igT3D1miNcQRh0zamKWuGdPcBOQ3XxZOxusZo+9dF K2RsWubSmdaH8PifmY0FBGBAOQ== X-Received: by 2002:a05:6830:3497:: with SMTP id c23mr1310200otu.253.1612974138446; Wed, 10 Feb 2021 08:22:18 -0800 (PST) Received: from eggly.attlocal.net (172-10-233-147.lightspeed.sntcca.sbcglobal.net. [172.10.233.147]) by smtp.gmail.com with ESMTPSA id 94sm466895otf.41.2021.02.10.08.22.17 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Wed, 10 Feb 2021 08:22:17 -0800 (PST) Date: Wed, 10 Feb 2021 08:22:00 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Johannes Weiner cc: Hugh Dickins , Andrew Morton , Michal Hocko , 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-writeback: simplify memcg handling in test_clear_page_writeback() In-Reply-To: Message-ID: References: <20210209214543.112655-1-hannes@cmpxchg.org> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 9 Feb 2021, Hugh Dickins wrote: > On Tue, 9 Feb 2021, Johannes Weiner wrote: > > > Page writeback doesn't hold a page reference, which allows truncate to > > free a page the second PageWriteback is cleared. This used to require > > special attention in test_clear_page_writeback(), where we had to be > > careful not to rely on the unstable page->memcg binding and look up > > all the necessary information before clearing the writeback flag. > > > > Since commit 073861ed77b6 ("mm: fix VM_BUG_ON(PageTail) and > > BUG_ON(PageWriteback)") test_clear_page_writeback() is called with an > > explicit reference on the page, and this dance is no longer needed. > > > > Use unlock_page_memcg() and dec_lruvec_page_stat() directly. > > s/stat()/state()/ > > This is a nice cleanup: I hadn't seen that connection at all. > > But I think you should take it further: > __unlock_page_memcg() can then be static in mm/memcontrol.c, > and its declarations deleted from include/linux/memcontrol.h? And further: void lock_page_memcg(page), not returning memcg. > > And further: delete __dec_lruvec_state() and dec_lruvec_state() > from include/linux/vmstat.h - unless you feel that every "inc" > ought to be matched by a "dec", even when unused. > > > > > Signed-off-by: Johannes Weiner > > Acked-by: Hugh Dickins > > > --- > > mm/page-writeback.c | 9 +++------ > > 1 file changed, 3 insertions(+), 6 deletions(-) > > > > diff --git a/mm/page-writeback.c b/mm/page-writeback.c > > index eb34d204d4ee..f6c2c3165d4d 100644 > > --- a/mm/page-writeback.c > > +++ b/mm/page-writeback.c > > @@ -2722,12 +2722,9 @@ EXPORT_SYMBOL(clear_page_dirty_for_io); > > int test_clear_page_writeback(struct page *page) > > { > > struct address_space *mapping = page_mapping(page); > > - struct mem_cgroup *memcg; > > - struct lruvec *lruvec; > > int ret; > > > > - memcg = lock_page_memcg(page); > > - lruvec = mem_cgroup_page_lruvec(page, page_pgdat(page)); > > + lock_page_memcg(page); > > if (mapping && mapping_use_writeback_tags(mapping)) { > > struct inode *inode = mapping->host; > > struct backing_dev_info *bdi = inode_to_bdi(inode); > > @@ -2755,11 +2752,11 @@ int test_clear_page_writeback(struct page *page) > > ret = TestClearPageWriteback(page); > > } > > if (ret) { > > - dec_lruvec_state(lruvec, NR_WRITEBACK); > > + dec_lruvec_page_state(page, NR_WRITEBACK); > > dec_zone_page_state(page, NR_ZONE_WRITE_PENDING); > > inc_node_page_state(page, NR_WRITTEN); > > } > > - __unlock_page_memcg(memcg); > > + unlock_page_memcg(page); > > return ret; > > } > > > > -- > > 2.30.0 >