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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A4F5AC0015E for ; Tue, 15 Aug 2023 20:07:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 25D8694002D; Tue, 15 Aug 2023 16:07:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 20E028D0001; Tue, 15 Aug 2023 16:07:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0D60D94002D; Tue, 15 Aug 2023 16:07:40 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id EF5798D0001 for ; Tue, 15 Aug 2023 16:07:39 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B2EA8140D04 for ; Tue, 15 Aug 2023 20:07:39 +0000 (UTC) X-FDA: 81127424238.26.A242830 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf23.hostedemail.com (Postfix) with ESMTP id C1CE5140018 for ; Tue, 15 Aug 2023 20:07:37 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=inE408hA; spf=none (imf23.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1692130058; a=rsa-sha256; cv=none; b=NEPXN3Vp8fsHOUiu4aFE0xXWeIfXgt6ogeXuxosLSYS45ZAt6irPYEB2KPWFrStXdV9+Po DnkAu8yb73Pj02auErcGSSh8bJoA1I6z+niPUdM5tin/CXoNCQLoHrz1bL887srM9hndEy YuHj6H1635j7wOwearPZzXYyCnZ+ECY= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=inE408hA; spf=none (imf23.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1692130058; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=eHSlXXQjPck8Fcx5Whhqhl8V7B9SR3BAERky3PV+PAQ=; b=awCWRHeyhOvQhhCilpmCog/i1ALW5M7fM4E5L+F07yqnjMXFQ2Nf3nHljcx4byhV5uMfcS I57vaVXPSQHOQtm6gv6JC1DwDTE1QyfMGOsBmBCPv1wTCIJYc0wri+vobZt1gwAiaRoLmR dC5HpXwttnFcdDWmtLK5TYZIGFLHZl0= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=eHSlXXQjPck8Fcx5Whhqhl8V7B9SR3BAERky3PV+PAQ=; b=inE408hAP8QYWNOne/4CmKKEva r/OJh5QBPUD+Dan6Sxqk/toBvQQExFZPZAGQ5VnVzz8ED/Ht9CGiS1wBVXZIEckqx6hZRVmeXTo+F z5Xe0u8C45iq+D/ydhEi5LUk6I7eDWOMP+DxaI29zUgU/JHv+e8BG8aCcrggqlDk7i8qc8/Svt/fR LuO5AG50jE6sQ+5P1ahCElfazbKoIOApklFvb+lnMr24bwRoqV3lxNNz+SWkWS9l7e+3uphJg6TS4 6iW7GBIci6GNDCWQBDaJb2J4zSobX3HHXOOgtz1Dp6S5R3h1MMxGoyJitrhuMCsleVekUiLkDaa63 qMG3v8Lg==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qW0KA-00AAXM-TM; Tue, 15 Aug 2023 20:07:30 +0000 Date: Tue, 15 Aug 2023 21:07:30 +0100 From: Matthew Wilcox To: Peter Xu Cc: Andrew Morton , Jens Axboe , io-uring@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH 8/9] mm: Rearrange page flags Message-ID: References: <20230815032645.1393700-1-willy@infradead.org> <20230815032645.1393700-9-willy@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: C1CE5140018 X-Stat-Signature: u5gwjm11pukogiimwtrpqwk73abys338 X-Rspam-User: X-HE-Tag: 1692130057-507479 X-HE-Meta: U2FsdGVkX18oHhPNoSqZu2wL/1/7eoIQpY0xY4oeGbpBpZIvu9kGXScJbxkKUAxKWwGD9a9/fWQlNaZBlwlFAKfdqrueZ0UUTPKibJ2grFosTeDGDQ9GjErCFXN3labk/azpu99vwlYjpy5DxGmTmQcCnudb2liN85va07Y3AEcojqOUyY/to+qjgiEFY9Jr762Mv2sNAsraL2Ytvi+2q2SHag5j4FFU9eQ/+7h7kKQtoWOwYZ5OECcPnTcHjlzRFThG8LLUXHUYisSXfhKakrHHeweHs8ScPIxcMogfMOlES9nVBf2At4YQo2Nf9/xkmcxzdXkPRIXRsQ+ZU/Bqwr4OYrcUaD5Vu/4Kx/6ASdUrnlj5IvQvPsysMMJXOA4FI8mPkEaWrJH5kwBeO/Cuf5LkuygwijO1tnDb21MWv8deu56eJ1v0/DOtyvhYhcqFOmqg0VOeU9O+WNCAO7W0F9YL2aP/AsK6+8hkh2Jdk7Tg+q3iL7FA/rxSuyJv5Ge8J3OTHwCtZG/cljqGdvxM4WBibHT7xxlvbBNgMDUlLwLyg/7XiXFTkGxl9Ne3Kegu/IUtVyyMPp5XDXxslsScdu8IUaZyE0bEwxRiPpQDJtNdQhuUmM2N7mNzLMajUPcCsHlG5FgqJdMKVH2sCvyqyRcPfPQ3/viMro/JoWHiS0Y3BcRSv8gSxreZjoVX+99fvmD2WKq4peeOcT/gCwsBEf3MK0rLK5Szq56/4Ch10h/EqaR3YutSWl2YTlwF5+S9q5WY7TehV7RGk39hm1Vh7tS0SUauDluGBaP9qVtIqbDxOZtfBHh2hhZwVNBVLgaD2rDw1b1AMayvgTeJdWeGVz+ZgsRdmdhX5k7LURNHeMx+0E1IV+4tOKVNI34WRi5MQXMrtNsSeLV+IN2mUD6FKeX8SPd4RpsrWUgxIO+VmB8vOIXzVDatkcJ7j1dRZLFWbqMCKdajIdeujZiKwKD xYK5KwYK dKZ77OjPw8S/G0+nLkZxTtfqQmfWW7YspGaqdfp1zs5shkO4qwlxWrOsA7Nh3Pe2f4uGlxizU7OxG6s4cwB7p9cWCmO3ATmFwLEldPn67tmRzdcsTLpHkQv1f5xB87uaZlASCQau3RwTvgqo= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000004, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Aug 15, 2023 at 03:24:16PM -0400, Peter Xu wrote: > On Tue, Aug 15, 2023 at 04:26:44AM +0100, Matthew Wilcox (Oracle) wrote: > > +++ b/include/linux/page-flags.h > > @@ -99,13 +99,15 @@ > > */ > > enum pageflags { > > PG_locked, /* Page is locked. Don't touch. */ > > + PG_writeback, /* Page is under writeback */ > > PG_referenced, > > PG_uptodate, > > PG_dirty, > > PG_lru, > > + PG_head, /* Must be in bit 6 */ > > Could there be some explanation on "must be in bit 6" here? Not on this line, no. You get 40-50 characters to say something useful. Happy to elaborate further in some other comment or in the commit log, but not on this line. The idea behind all of this is that _folio_order moves into the bottom byte of _flags_1. Because the order can never be greater than 63 (and in practice I think the largest we're going to see is about 30 -- a 16GB hugetlb page on some architectures), we know that PG_head and PG_waiters will be clear, so we can write (folio->_flags_1 & 0xff) and the compiler will just load a byte; it won't actually load the word and mask it. We can't move PG_head any lower, or we'll risk having a tail page with PG_head set (which can happen with the vmemmmap optimisation, but eugh). And we don't want to move it any higher because then we'll have a flag that cannot be reused in a tail page. Bit 6 is the perfect spot for it.