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=-23.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL 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 D5196C433E0 for ; Fri, 26 Feb 2021 20:22:15 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 32CA664E6B for ; Fri, 26 Feb 2021 20:22:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32CA664E6B 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 A1AAA6B0075; Fri, 26 Feb 2021 15:22:14 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 9CB996B0078; Fri, 26 Feb 2021 15:22:14 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8E1286B007B; Fri, 26 Feb 2021 15:22:14 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0233.hostedemail.com [216.40.44.233]) by kanga.kvack.org (Postfix) with ESMTP id 78EBC6B0075 for ; Fri, 26 Feb 2021 15:22:14 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 3CA76181AF5CC for ; Fri, 26 Feb 2021 20:22:14 +0000 (UTC) X-FDA: 77861540988.30.14E4A8D Received: from mail-io1-f49.google.com (mail-io1-f49.google.com [209.85.166.49]) by imf05.hostedemail.com (Postfix) with ESMTP id D04ECE000101 for ; Fri, 26 Feb 2021 20:22:12 +0000 (UTC) Received: by mail-io1-f49.google.com with SMTP id p16so10978152ioj.4 for ; Fri, 26 Feb 2021 12:22:13 -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:in-reply-to; bh=RHa2D7KXPMnadDnKBMg5+XM2s/0n45bECjcvpilBAc0=; b=bwU1TglRUXTJnraQwHDvZD9CDXHZFQZP74++szcIfuNLJ+zQ59aHKRCDNcwTNCiEM7 9UNBEWQzmPyHlKw48wu5v5eChRicQKmLLN3U6Vw/eO7ulv/RekEeg3NGfS5vFGS18zK1 dtv89qFIdM//PAJDSUk253l84BhBZE6FN6JKTyrZ72XeWzMGVYGE/I+EG81lSGwEoVnw Gi2EBfIv7pTyy5dZueLwklNyBgMNIBO2p9Nu8eEMweSCJMOiKlDmiLkDBKhC3YGu6q2Q m8M6+PZMTJRAWTDRsIrQHksmcnTZuSMfwaGzkzg7W8SSFYGJ7V+ZkgGjA62fRiqUP/sa nxHA== 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:in-reply-to; bh=RHa2D7KXPMnadDnKBMg5+XM2s/0n45bECjcvpilBAc0=; b=KtQ8vhMNbN7XnKLqW41x6Fzf64NujYCi7LZJYhAGgGsU6wGXYTNGL1n99a4lTeZ7nx SzIiUYYiRemkmA6Uyyo+KOsNtFSejZig90b7qfxku8FZpu12vHiuqudH59Lfpi8ui0ye oiJAIIn1BJctKDV7X7nGfjzFkFauPnvJnaTCrD/BWn1Qgvzcr57IB6mk2dzCI+vzbgfs sUWBVd5HfWk0Set0JeZRw4lD3I3PqDwZE4gLr/s3I8buig2m237Bp3jz4fnls2nwZbxd +6saBVECCk1ucS4YIu54lcjQ0Jw7j25f1/t9EgnvT3Uvbl8mIMs0YwTSTUsTPsTQHEvM VJRg== X-Gm-Message-State: AOAM530a6+0LlyXTjKqcLOStY4rrnK6oZyj5u+XGXfSLO2PddA+l/F/v E5BJWtQk3VyqIxYMZ7vaIEN4gA== X-Google-Smtp-Source: ABdhPJzoe/ddEaVDeSLVgtONhm5KgOQazvs43ameu+yB/9lPqSPaQH+A8djeSriYr4Z251T+osDjRQ== X-Received: by 2002:a5d:814f:: with SMTP id f15mr4277064ioo.14.1614370933029; Fri, 26 Feb 2021 12:22:13 -0800 (PST) Received: from google.com ([2620:15c:183:200:bd06:d32d:458e:cd3a]) by smtp.gmail.com with ESMTPSA id a14sm4922614ilj.39.2021.02.26.12.22.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Feb 2021 12:22:12 -0800 (PST) Date: Fri, 26 Feb 2021 13:22:08 -0700 From: Yu Zhao To: akpm@linux-foundation.org, alex.shi@linux.alibaba.com, vbabka@suse.cz, willy@infradead.org, "Kirill A. Shutemov" Cc: guro@fb.com, hannes@cmpxchg.org, hughd@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mhocko@kernel.org, vdavydov.dev@gmail.com Subject: Re: [PATCH v2 2/3] mm: use PF_NO_TAIL for PG_lru Message-ID: References: <20210224084807.2179942-1-yuzhao@google.com> <20210226091718.2927291-1-yuzhao@google.com> <20210226091718.2927291-3-yuzhao@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210226091718.2927291-3-yuzhao@google.com> X-Stat-Signature: rwfqdhbdsk3rgz3w1jqob59oerg7nwxg X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: D04ECE000101 Received-SPF: none (google.com>: No applicable sender policy available) receiver=imf05; identity=mailfrom; envelope-from=""; helo=mail-io1-f49.google.com; client-ip=209.85.166.49 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1614370932-821829 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 Fri, Feb 26, 2021 at 02:17:17AM -0700, Yu Zhao wrote: > Trying to set or clear PG_lru on tail pages has been considered buggy. > Enforce this rule by changing the policy for PG_lru from PF_HEAD to > PF_NO_TAIL. This means setting or clearing PG_lru on tail pages won't > be "corrected" by compound_page(). Such "correction" isn't helpful -- > even if a piece of buggy code has gotten away with > compound_page(tail)->flags, it will run into trouble with lru list > addition and deletion because they use tail->lru rather than > compound_page(tail)->lru. > > bloat-o-meter result: > add/remove: 0/0 grow/shrink: 0/11 up/down: 0/-535 (-535) > > Signed-off-by: Yu Zhao > --- > include/linux/page-flags.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > index 1995208a3763..c9626e54df8d 100644 > --- a/include/linux/page-flags.h > +++ b/include/linux/page-flags.h > @@ -333,8 +333,8 @@ PAGEFLAG(Referenced, referenced, PF_HEAD) > __SETPAGEFLAG(Referenced, referenced, PF_HEAD) > PAGEFLAG(Dirty, dirty, PF_HEAD) TESTSCFLAG(Dirty, dirty, PF_HEAD) > __CLEARPAGEFLAG(Dirty, dirty, PF_HEAD) > -PAGEFLAG(LRU, lru, PF_HEAD) __CLEARPAGEFLAG(LRU, lru, PF_HEAD) > - TESTCLEARFLAG(LRU, lru, PF_HEAD) As a side note, IMO, testing PG_lru on compound_head(tail)->flags is a bug because it defeats the purpose of the following pattern when, e.g., racing with compound page creations. This pattern is intended to avoid dirtying struct page cache line when scanning PFNs speculatively in isolate_migratepages_block() and page_idle_get_page(). Without compound_head(), it works well when it misses head pages. But with compound_head(), get_page_unless_zero() will run unnecessarily on tail pages. if (!PageLRU(page) || !get_page_unless_zero(page)) continue; if (!PageLRU(page)) { put_page(page); continue; } do_something();