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 7C109C433F5 for ; Thu, 12 May 2022 20:55:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0DC9A6B0075; Thu, 12 May 2022 16:55:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 08C026B0078; Thu, 12 May 2022 16:55:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E95FF8D0001; Thu, 12 May 2022 16:55:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id DB25D6B0075 for ; Thu, 12 May 2022 16:55:04 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id BAE6A12091C for ; Thu, 12 May 2022 20:55:04 +0000 (UTC) X-FDA: 79458295728.13.021AC99 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf02.hostedemail.com (Postfix) with ESMTP id BDFBD800C0 for ; Thu, 12 May 2022 20:54:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=YA1cDGpFFJSqloLayCUCKn0nstXcZ43lg1pMoX0HvTk=; b=KBVkmD5ngM2fMHixgZw6aS95Ai mRAbSGZ0a5/p/blPr2WVPfy2DZ1vf5fqdbyquLfuDoWwOKF83C4In8GE+aSu9ckGwoEsp/T2+UqJ2 DYhprPMDyCz+n7kLLERjv85H9CQtmLE/Sf9Nam+Wwj3sYruLDzw+ixFwFkv0naXQP16OnZJFnY4iB ZZfwSThC6JV/SzbbNfEHRAJcwIiI/dbFxNyPzSrA3DdKhmepa/2L89Qlk2UjhHf6WzcfwH+MaBnkH 5Z7t/5q6qGlRiDcEKPsNNLgaFL1t03z2re6+Ctxl3KZxVvFOOKzkH6tCagH/T/W5OY7VQbspG3MDj Udu8SSmQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1npFpr-006jx0-FJ; Thu, 12 May 2022 20:54:59 +0000 Date: Thu, 12 May 2022 21:54:59 +0100 From: Matthew Wilcox To: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Freeing page flags Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=KBVkmD5n; dmarc=none; spf=none (imf02.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: BDFBD800C0 X-Rspam-User: X-Stat-Signature: 6wy6zgfyh7iwrom4amj83z8ybmj3s18t X-HE-Tag: 1652388895-612171 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: The LWN writeup [1] on merging the MGLRU reminded me that I need to send out a plan for removing page flags that we can do without. 1. PG_error. It's basically useless. If the page was read successfully, PG_uptodate is set. If not, PG_uptodate is clear. The page cache doesn't use PG_error. Some filesystems do, and we need to transition them away from using it. 2. PG_private. This tells us whether we have anything stored at page->private. We can just check if page->private is NULL or not. No need to have this extra bit. Again, there may be some filesystems that are a bit wonky here, but I'm sure they're fixable. 3. PG_mappedtodisk. This is really only used by the buffer cache. Once the filesystems that use bufferheads have been converted, this can go away. 4. I think I can also consolidate PG_slab and PG_reserved into a "single bit" (not really, but change the encoding so that effectively they only take a single bit). That gives us 4 bits back, which should relieve the pressure on page flag bits for a while. I have Thoughts on PG_private_2 and PG_owner_priv_1, as well as a suspicion that not all combinations of referenced, lru, active, workingset, reclaim and unevictable are possible, and there might be scope for a better encoding. But I don't know that we need to do that work; gaining back 4 bits is already a Big Deal. I'm slowly doing the PG_private transition as part of the folio work. For example, eagle eyed reviewers may have spotted that there is no folio_has_buffers(). Converted code calls folio_buffers() and checks if it's NULL. Help from filesystem maintainers on removing the uses of PG_error gratefully appreciated. [1] https://lwn.net/Articles/894859/