Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp1137022pxb; Wed, 10 Feb 2021 00:33:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJyD4LLqQSiXFAyvNtl4jTJYT+qA36o67E04aONouJbiEP2qMfZTH2gFeksFwKdkMPCHFpE7 X-Received: by 2002:a17:906:b217:: with SMTP id p23mr1949976ejz.126.1612946014202; Wed, 10 Feb 2021 00:33:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1612946014; cv=none; d=google.com; s=arc-20160816; b=S9znFjok3wvzdLpHawsUPmeA4CWTm6cw1Qwc+Ly24wtctQZWY7C8bNflCogTdjPpe5 DHzdUOHLM+vwV75qkZPW0gfeGaXVDP8Z7oMAlzWTN8s26EWuecAJ1M557XNIKctUz/0w LrqBZB2hVU+1H02JDsaWjQY+y8l5ko5zEUjGraf/p5rK5ke88pARRp+z+EEGmN+S1HMe VDR9E6AO7bNiCLeX8RXiDBRwTgXgadOTdL9Azif62D8/8biMezBEKGDmhK/vRgwIpYFY LZO/Sf3dUtkLVFOlEchLD4TuCKTHvvGgnk88SxfpjmjW9Fdn6ke2paMvN+MbuMS5gvBU RHBQ== 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=Q8+AD77bMtoNW/HBzmZ8xMNYIgN4sAwD1/ADY3ZtEEk=; b=iqGzMoSAWt0lS0vmV08r/TDsj5hydZhNy6AITnFDjOFZw7DjHhAZFRHuD/L/yefEqz AmVlGBE3esY0R0+5wEGvPfS2yhCW9nUkYyVEd3cxcATilsdOL3gNfp263sfgahCHMnPt IApLtdGMtvU5HOiD3z0kcVDIwLVOuywA6FTq/F7uKwDocB2uBDUDDjoHRZ6NXuMHkenK LDhjUIV3OfBdtfsvoQzKf9fMv7BLOKDRKOYEDbJqhGIfO0Aqskm0DeYgpXUSq8kcMPQN OylZ6KC0xmgtqRahwIhUj36azMchKIcjIoQSdkbLaCiYk2qv4xvxBAUB6Ie6N66WKPKd ZDXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Fdroa3m7; 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 c59si904788edd.508.2021.02.10.00.33.10; Wed, 10 Feb 2021 00:33:34 -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=Fdroa3m7; 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 S229942AbhBJFRh (ORCPT + 99 others); Wed, 10 Feb 2021 00:17:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36094 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229609AbhBJFRh (ORCPT ); Wed, 10 Feb 2021 00:17:37 -0500 Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 32425C061574 for ; Tue, 9 Feb 2021 21:16:51 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id k10so753641otl.2 for ; Tue, 09 Feb 2021 21:16:51 -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=Q8+AD77bMtoNW/HBzmZ8xMNYIgN4sAwD1/ADY3ZtEEk=; b=Fdroa3m70eD8+7KTxXuHTcUNnT7RKmI2+/ujf5yGEJfyh0W9IHuWdQ5VrHoRK6KiKO orVrw72k5YjskoOG5UvgLdG/VhwDwAzL+AT5d8n9kKs8NOrUjf1eD9km4BYGH86kloyE na4Au9OoCTeFEnN4rZy0olzery/o76zJWHL/F4q0Er3uC2Wu2BN/BydsGVBJ9vFNEjv3 DGOM99xnrf4CLCxsyb52Jb4BBg+fytIkav8i4ZzrLv+joPRR4Zjr5LcjOKlhUVM9M64i yf1ht/CMGODtIeTCmM5Y/XlMCZ7q21rDcMYbIM7kF3RiQZGI0RCBgeQvIwBdMrMHhydS lARA== 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=Q8+AD77bMtoNW/HBzmZ8xMNYIgN4sAwD1/ADY3ZtEEk=; b=iCLECZHlXN5fpukKL5QVV6FnCq9SWp/wl3yMQjaztezbzKAhKJLunvDswnyOgT4Zrr hIwbH17jGS6pudFQQPjpj73kdSao3iwXwrZxStNwp6sk2W1f2PUYI1oPzkxcqr8bl3Gb Lgc5DArfHMl/+A75fyRsJKCzZCPtDiJ2Suzy/LZTGid1bFB6DcOmhoQ4F8vORgxEW70e +Wmrs7kR9B97LiUAPbeY1ClP4CO8I+n+8n066Ebmvf5Y/iQRrm3zNB3fGGABf1ZQz6aH 7BMc3LT1P89HkCm6r5HA7Id7IA94A87EFl1xxQHf5q5yU5hP5zqe2JyaM8q+L7DBw4NG h44w== X-Gm-Message-State: AOAM532d99ZWo6B+9E8eQUWA1Iw/CHNKnr8nK0h8fE4mDGpwgl4FnIvi USvtmbmAOO8EjVvuFnjbTQrm9g== X-Received: by 2002:a9d:5d02:: with SMTP id b2mr915507oti.148.1612934210367; Tue, 09 Feb 2021 21:16:50 -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 w2sm195062otq.9.2021.02.09.21.16.48 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Tue, 09 Feb 2021 21:16:49 -0800 (PST) Date: Tue, 9 Feb 2021 21:16:37 -0800 (PST) From: Hugh Dickins X-X-Sender: hugh@eggly.anvils To: Johannes Weiner cc: Andrew Morton , Hugh Dickins , 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: <20210209214543.112655-1-hannes@cmpxchg.org> 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, 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: 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