linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: "Kirill A. Shutemov" <kirill@shutemov.name>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: Re: State of the Page (August 2022)
Date: Fri, 12 Aug 2022 15:39:09 +0100	[thread overview]
Message-ID: <YvZmDfSFMydiulzw@casper.infradead.org> (raw)
In-Reply-To: <20220812143356.4kv5cycwbcy2t7ul@box.shutemov.name>

On Fri, Aug 12, 2022 at 05:33:56PM +0300, Kirill A. Shutemov wrote:
> If you really need info about these pages and reference their memdesc it
> is likely be 9 cache lines that scattered across memory instead of 8 cache
> lines next to each other in the same page.

Well, hopefully not.  Most allocations should be multiple pages.  That's
already true for slab, netpool and file (for xfs anyway), and hopefully
soon for anon.

> Initially, I thought we can offset the cost by caching memdescs instead of
> struct page/folio. Like page cache store memdesc, but it would require
> memdesc_to_pfn() which is not possible, unless we want to store pfn
> explicitly in memdesc.

I think we do, at least for some memdescs.  File folios definitely want
to store the pfn, but I don't think getting the PFN for a slab is a
common operation (although we'll still need to store the pointer to
the struct page, so it's equivalent).

> I don't want to be buzzkill, I like the idea a lot, but abstractions are
> often costly. Getting it upstream without noticeable performance
> regressions going to be a challenge.

I don't think there's a way to find out whether it'll be a performance
win without actually doing it.  Fortunately, the steps to get to this
point are mostly good cleanups anyway.



  reply	other threads:[~2022-08-12 14:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-11 21:31 State of the Page (August 2022) Matthew Wilcox
2022-08-12 10:16 ` Kirill A. Shutemov
2022-08-12 13:34   ` Matthew Wilcox
2022-08-12 14:33     ` Kirill A. Shutemov
2022-08-12 14:39       ` Matthew Wilcox [this message]
2022-08-13 15:21 ` Mike Rapoport
2022-08-14 10:57   ` Matthew Wilcox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YvZmDfSFMydiulzw@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=kirill@shutemov.name \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).