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=-8.5 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,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 49355C433E0 for ; Wed, 24 Feb 2021 08:37:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A6E29601FF for ; Wed, 24 Feb 2021 08:37:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A6E29601FF Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 250626B0006; Wed, 24 Feb 2021 03:37:31 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DAF96B006C; Wed, 24 Feb 2021 03:37:31 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07B586B006E; Wed, 24 Feb 2021 03:37:31 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0222.hostedemail.com [216.40.44.222]) by kanga.kvack.org (Postfix) with ESMTP id E0D866B0006 for ; Wed, 24 Feb 2021 03:37:30 -0500 (EST) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 6B26E9063 for ; Wed, 24 Feb 2021 08:37:30 +0000 (UTC) X-FDA: 77852507460.14.5848AA1 Received: from mail-il1-f171.google.com (mail-il1-f171.google.com [209.85.166.171]) by imf18.hostedemail.com (Postfix) with ESMTP id 05CF62000395 for ; Wed, 24 Feb 2021 08:37:30 +0000 (UTC) Received: by mail-il1-f171.google.com with SMTP id g9so1061644ilc.3 for ; Wed, 24 Feb 2021 00:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=U5WMw2iN95z0AMy1MV8rFaVMuu5LHFDpfbdSEGsP6SM=; b=OCVKcX1eyy82VQgHA/u7ZPi01D0r2gQAjBzoKmRXW0o9g2vqh+WLoao38jolMEwrIo EOMHpjU54voo50qx3a4MfaIQeydX5jAGupenuCU21UerPZuBmtCl83l+XntDbXgA9Qt1 KGBSrc+/CEQfNGBLu9fecEdG6VU3Fk4eqbrgEN00D6TuYOr0CtYPuJNOTPQAP4xamBFJ U8McBHPZsDJsDn9IpPVe9sv5bzwJN9x6+N8GYUDoQIRMCAcuFS8uZDnBsT6QVY/zL4bI 08ezVhC8uAjTw9vOtpbW97VIIYCZYxQIP/STCXFRap+5krSkdS4H8UtB8cIihrjzPG11 9vBw== 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:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=U5WMw2iN95z0AMy1MV8rFaVMuu5LHFDpfbdSEGsP6SM=; b=OtC+TClZ6RpRQu1Z3pPDlAOOqaBXznsZmz1nIlTe9wHBBGme+7sbkj41e6BzdEZuyJ OXsAozZvVb4ssk0kjC28m0rqnTStLwacV+6Kca5Ri2k5a5Y9dheBxL3pSUZPhUYhopOv 4QBiOuRpnmzVaJzIg8NYHDtetilabmW5CIJ7s9d55WZIXznh3mLDJ9rISlWqSH791y+i HWV2Br60gjcRu8HVqkVjKP3o+vxvg1BH79NyuS9L2D+fmRBsJJ1XjcOPUwsIGagubkJy BMNMwEJee+Eiem52dlC6NmgSB3bNW9jEtuPS8crf2y7rqfNzW+RyDzHN2V5FhnOoLkxg 3DaA== X-Gm-Message-State: AOAM532Bma6RkUwdtqB6dhvhNlwPcW9iqzRaIvG0t7ohCC76FMk4AxZc GY+CQsNDx1Crhaq0eXeruQ+dbQ== X-Google-Smtp-Source: ABdhPJyn63Mrg7X9DMVFxR92Wy+Jasaavl6P0MVm6G0wgUP4OBVEOvm5J8g2Kj0IW7NoUZiAjyBxag== X-Received: by 2002:a92:194a:: with SMTP id e10mr24084102ilm.213.1614155848895; Wed, 24 Feb 2021 00:37:28 -0800 (PST) Received: from google.com ([2620:15c:183:200:e588:e0b1:9ba0:55be]) by smtp.gmail.com with ESMTPSA id a14sm1330867ilm.68.2021.02.24.00.37.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Feb 2021 00:37:28 -0800 (PST) Date: Wed, 24 Feb 2021 01:37:24 -0700 From: Yu Zhao To: Alex Shi Cc: Andrew Morton , Matthew Wilcox , Vlastimil Babka , Hugh Dickins , Michal Hocko , Johannes Weiner , Vladimir Davydov , Roman Gushchin , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 03/10] mm: don't pass "enum lru_list" to lru list addition functions Message-ID: References: <20210122220600.906146-1-yuzhao@google.com> <20210122220600.906146-4-yuzhao@google.com> <20210126220111.GO308988@casper.infradead.org> <20210223145011.0181eed96ab0091a493b51f6@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 05CF62000395 X-Stat-Signature: ga5ydngf98qbrncqgwet8mqxaxg979hu Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf18; identity=mailfrom; envelope-from=""; helo=mail-il1-f171.google.com; client-ip=209.85.166.171 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614155850-133305 Content-Transfer-Encoding: quoted-printable 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 Wed, Feb 24, 2021 at 04:06:45PM +0800, Alex Shi wrote: >=20 >=20 > =E5=9C=A8 2021/2/24 =E4=B8=8B=E5=8D=881:29, Yu Zhao =E5=86=99=E9=81=93: > > On Tue, Feb 23, 2021 at 02:50:11PM -0800, Andrew Morton wrote: > >> On Tue, 26 Jan 2021 15:14:38 -0700 Yu Zhao wrote= : > >> > >>> On Tue, Jan 26, 2021 at 10:01:11PM +0000, Matthew Wilcox wrote: > >>>> On Fri, Jan 22, 2021 at 03:05:53PM -0700, Yu Zhao wrote: > >>>>> +++ b/mm/swap.c > >>>>> @@ -231,7 +231,7 @@ static void pagevec_move_tail_fn(struct page = *page, struct lruvec *lruvec) > >>>>> if (!PageUnevictable(page)) { > >>>>> del_page_from_lru_list(page, lruvec, page_lru(page)); > >>>>> ClearPageActive(page); > >>>>> - add_page_to_lru_list_tail(page, lruvec, page_lru(page)); > >>>>> + add_page_to_lru_list_tail(page, lruvec); > >>>>> __count_vm_events(PGROTATED, thp_nr_pages(page)); > >>>>> } > >>>> > >>>> Is it profitable to do ... > >>>> > >>>> - del_page_from_lru_list(page, lruvec, page_lru(page)); > >>>> + enum lru_list lru =3D page_lru(page); > >>>> + del_page_from_lru_list(page, lruvec, lru); > >>>> ClearPageActive(page); > >>>> - add_page_to_lru_list_tail(page, lruvec, page_lru(page)); > >>>> + lru &=3D ~LRU_ACTIVE; > >>>> + add_page_to_lru_list_tail(page, lruvec, lru); > >>> > >>> Ok, now we want to trade readability for size. Sure, I'll see how > >>> much we could squeeze. > >> > >> As nothing has happened here and the code bloat issue remains, I'll > >> hold this series out of 5.12-rc1. > >=20 > > Sorry for the slow response. I was trying to ascertain why > > page_lru(), a tiny helper, could bloat vmlinux by O(KB). It turned ou= t > > compound_head() included in Page{Active,Unevictable} is a nuisance in > > our case. Testing PG_{active,unevictable} against > > compound_head(page)->flags is really unnecessary because all lru > > operations are eventually done on page->lru not > > compound_head(page)->lru. With the following change, which sacrifices > > the readability a bit, we gain 998 bytes with Clang but lose 227 byte= s > > with GCC, which IMO is a win. (We use Clang by default.) > >=20 > >=20 > > diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h > > index 355ea1ee32bd..ec0878a3cdfe 100644 > > --- a/include/linux/mm_inline.h > > +++ b/include/linux/mm_inline.h > > @@ -46,14 +46,12 @@ static __always_inline void __clear_page_lru_flag= s(struct page *page) > > { > > VM_BUG_ON_PAGE(!PageLRU(page), page); > > =20 > > - __ClearPageLRU(page); > > - > > /* this shouldn't happen, so leave the flags to bad_page() */ > > - if (PageActive(page) && PageUnevictable(page)) > > + if ((page->flags & (BIT(PG_active) | BIT(PG_unevictable))) =3D=3D > > + (BIT(PG_active) | BIT(PG_unevictable))) > > return; > > =20 > > - __ClearPageActive(page); > > - __ClearPageUnevictable(page); > > + page->flags &=3D ~(BIT(PG_lru) | BIT(PG_active) | BIT(PG_unevictabl= e)); > > } > > =20 > > /** > > @@ -65,18 +63,12 @@ static __always_inline void __clear_page_lru_flag= s(struct page *page) > > */ > > static __always_inline enum lru_list page_lru(struct page *page) > > { > > - enum lru_list lru; > > + unsigned long flags =3D READ_ONCE(page->flags); > > =20 > > VM_BUG_ON_PAGE(PageActive(page) && PageUnevictable(page), page); > > =20 > > - if (PageUnevictable(page)) > > - return LRU_UNEVICTABLE; > > - > > - lru =3D page_is_file_lru(page) ? LRU_INACTIVE_FILE : LRU_INACTIVE_A= NON; > > - if (PageActive(page)) > > - lru +=3D LRU_ACTIVE; > > - > > - return lru; > > + return (flags & BIT(PG_unevictable)) ? LRU_UNEVICTABLE : > > + (LRU_FILE * !(flags & BIT(PG_swapbacked)) + !!(flags & BIT(P= G_active))); >=20 > Currently each of page flags used different flags policy, does this mea= n above flags could be > change to PF_ANY policy? That's a good question. Semantically, no because PG_{active,unevictable} only apply to head pages. But practically, I think the answer is yes, and the only place that needs to explicitly call compound_head() is gather_stats() in fs/proc/task_mmu.c, IIRC. >=20 > Thanks > Alex >=20 > > } > > =20 > > static __always_inline void add_page_to_lru_list(struct page *page, > >=20 > >=20 > > I'll post this as a separate patch. Below the bloat-o-meter collected > > on top of c03c21ba6f4e. > >=20 > > $ ./scripts/bloat-o-meter ../vmlinux.clang.orig ../vmlinux.clang > > add/remove: 0/1 grow/shrink: 7/10 up/down: 191/-1189 (-998) > > Function old new delta > > lru_lazyfree_fn 848 893 +45 > > lru_deactivate_file_fn 1037 1075 +38 > > perf_trace_mm_lru_insertion 515 548 +33 > > check_move_unevictable_pages 983 1006 +23 > > __activate_page 706 729 +23 > > trace_event_raw_event_mm_lru_insertion 476 497 +21 > > lru_deactivate_fn 691 699 +8 > > __bpf_trace_mm_lru_insertion 13 11 -2 > > __traceiter_mm_lru_insertion 67 62 -5 > > move_pages_to_lru 964 881 -83 > > __pagevec_lru_add_fn 665 581 -84 > > isolate_lru_page 524 419 -105 > > __munlock_pagevec 1609 1481 -128 > > isolate_migratepages_block 3370 3237 -133 > > __page_cache_release 556 413 -143 > > lruvec_lru_size 151 - -151 > > release_pages 1025 866 -159 > > pagevec_move_tail_fn 805 609 -196 > > Total: Before=3D19502982, After=3D19501984, chg -0.01% > >=20 > > $ ./scripts/bloat-o-meter ../vmlinux.gcc.orig ../vmlinux.gcc > > add/remove: 0/1 grow/shrink: 9/9 up/down: 1010/-783 (227) > > Function old new delta > > shrink_lruvec 1690 1950 +260 > > lru_deactivate_file_fn 961 1128 +167 > > isolate_migratepages_block 3286 3427 +141 > > check_move_unevictable_pages 1042 1170 +128 > > lru_lazyfree_fn 709 822 +113 > > lru_deactivate_fn 665 724 +59 > > __activate_page 703 760 +57 > > trace_event_raw_event_mm_lru_insertion 432 478 +46 > > perf_trace_mm_lru_insertion 464 503 +39 > > __bpf_trace_mm_lru_insertion 13 11 -2 > > __traceiter_mm_lru_insertion 66 57 -9 > > isolate_lru_page 472 405 -67 > > __munlock_pagevec 1282 1212 -70 > > __pagevec_lru_add 976 893 -83 > > __page_cache_release 508 418 -90 > > release_pages 978 887 -91 > > move_pages_to_lru 954 853 -101 > > lruvec_lru_size 131 - -131 > > pagevec_move_tail_fn 770 631 -139 > > Total: Before=3D19237248, After=3D19237475, chg +0.00% > >=20