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 47C15C433F5 for ; Fri, 13 May 2022 03:47:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AD2776B0073; Thu, 12 May 2022 23:47:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A7F286B0075; Thu, 12 May 2022 23:47:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 946386B0078; Thu, 12 May 2022 23:47:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 837D76B0073 for ; Thu, 12 May 2022 23:47:31 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5079231D03 for ; Fri, 13 May 2022 03:47:31 +0000 (UTC) X-FDA: 79459335102.23.007EC24 Received: from mail-vk1-f171.google.com (mail-vk1-f171.google.com [209.85.221.171]) by imf13.hostedemail.com (Postfix) with ESMTP id 215C9200AA for ; Fri, 13 May 2022 03:47:11 +0000 (UTC) Received: by mail-vk1-f171.google.com with SMTP id e144so3626724vke.9 for ; Thu, 12 May 2022 20:47:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zMLk1Ay+Dq4Ta56iDG7dM32hpID8fSkg4kAmLD778ok=; b=caPJHttEez05Vmo1EY25yNiTf5aMepNmLUt0WkY3lFFYxKSq/9CC3uVzsYZpO0NFi3 C/7nRIPjDHSWiqsNmCzOXt6VeBAiJbrxIGgkApZzElmTCg8bhRTG2NO6Tpvx4HhNq+XS XGSmBTNh/P2kTShOISVxQfanQqPcZnMo41ouGZAzUSWLp14RzCaQE8O6cjp8heqQ5Dlu HAorm7X+ZmMmDRGnTHzwzRc7Un//zcN2uZEH0K0ApmLwDTpoTm71KRlBlxRg4IIAL2F5 TGPZEZRK97j3RF4thOWAB40zkId+FBDnSRXT8hwzCxl2VPGsu77TiD9ZNdXrtU7ZWXXL 7zMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zMLk1Ay+Dq4Ta56iDG7dM32hpID8fSkg4kAmLD778ok=; b=rIJOaGfC/Uq8SmLjxJI3VQh/zcW71oQ7mDGvIM6UHyK5UcHikl3OxupYfN1sVuKlNC h6Qyw5XXqBCoQVgtmObwgh9YVFAmSZNWIryXV/TRmwyi9YRTzWWqYdLJnWzX2YOXaWFp xAjW/MVmndnPU8zUjcnRWM7B3QtKGmkwudKKPZY18uNdGnA1e+4CDAQ5qSpOiRyDTHwN x4m3tu5rmPzsQQotVGpJbcdJVxdZpXvqvfeEUtYYwfxrfkLaoXfz07KuGv9L9L/4Z+aG iazGzvpPjtB02uFEOY7+MU6qg+IozgajX2xxYL0uVETN13PR441WDqNXfcIEtp/mSJPR B5zg== X-Gm-Message-State: AOAM531jIc2XgA9BiST9NCH91WbbWYFLU6J1Hmbd1qiJLdu4fhY2ay/q v2uQXkFKROQcXmZ/dycsGwxudx3IJv1WoBtcYnPDPw== X-Google-Smtp-Source: ABdhPJxV0TetOu+mRPeQoHxb7dsAS7IbYg8HeKbEJMIVBQ1No7E0qF1ZLEHUpf0gg4dJuTVuzCor3TMukC/4GEBpEgc= X-Received: by 2002:a1f:ec45:0:b0:34e:6cdc:334e with SMTP id k66-20020a1fec45000000b0034e6cdc334emr1600555vkh.26.1652413649607; Thu, 12 May 2022 20:47:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yu Zhao Date: Thu, 12 May 2022 21:46:53 -0600 Message-ID: Subject: Re: Freeing page flags To: Matthew Wilcox Cc: linux-fsdevel@vger.kernel.org, Linux-MM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 215C9200AA X-Stat-Signature: ix4bc8eprq3nq11uo4rynroak14woddc X-Rspam-User: Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=caPJHttE; spf=pass (imf13.hostedemail.com: domain of yuzhao@google.com designates 209.85.221.171 as permitted sender) smtp.mailfrom=yuzhao@google.com; dmarc=pass (policy=reject) header.from=google.com X-HE-Tag: 1652413631-601094 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 Thu, May 12, 2022 at 2:55 PM Matthew Wilcox wrote: > > 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. Much appreciated. > 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. PG_active, PG_ unevictable and PG_swapbacked seem to be the low hanging fruit among those you mentioned above. They indicate which LRU list a folio is currently on, was deleted from or should be added to. We should be able to use the spare bits in folio->lru for this purpose. WDYT? > 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/ We'd be very happy to help with testing and reviewing, etc.