linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kent Overstreet <kent.overstreet@gmail.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: hannes@cmpxchg.org, willy@infradead.org, rientjes@google.com
Subject: Compaction & folios
Date: Wed, 6 Oct 2021 18:53:41 -0400	[thread overview]
Message-ID: <YV4o9SxfYuLm1i4d@moria.home.lan> (raw)

So I have some observations on memory compaction & hugepages.

Right now, the working assumption in MM is that compaction is hard and
expensive, and right now it is - because most allocations are order 0, with a
small subset being hugepage order allocations. This means any time we need a
hugepage, compaction has to move a bunch of order 0 pages around, and memory
reclaim is no help here - when we reclaim memory, it's coming back as fragmented
order 0 pages.

But what if compaction wasn't such a difficult, expensive operation?

With folios, and then folios for anonymous pages, we won't see nearly so many
order 0 allocations anymore - we'll see a spread of allocation sizes based on a
mixture of application usage patterns - something much closer to a poisson
distribution, vs. our current very bimodal distribution. And since we won't be
fragmenting all our allocations up front, memory reclaim will be freeing
allocations in this same distribution.

Which means that any time an order n allocation fails, it's likely that we'll
still have order n-1 pages free - and of those free order n-1 pages, one will
likely have a buddy that's moveable and hasn't been fragmented - meaning the
common case is that compaction will have to move _one_ (higher order) page -
we'll almost never be having to move a bunch of 4k pages.

Another way of thinking of this is that memory reclaim will be doing most of the
work that compaction has to do now to allocate a high order page. Compaction
will go from an expensive, somewhat unreliable operation to one that mostly just
works - it's going to be _much_ less of a pain point.

It may turn out that allocating hugepages still doesn't work as reliably as we'd
like - but folios are still a big help even when we can't allocate a 2MB page,
because we'll be able to fall back to an order 6 or 7 or 8 allocation, which is
something we can't do now. And, since multiple CPU vendors now support
coalescing contiguous PTE entries in the TLB, this will still get us most of the
performance benefits of using hugepages.


             reply	other threads:[~2021-10-06 22:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-06 22:53 Kent Overstreet [this message]
2021-10-06 23:17 ` Compaction & folios Matthew Wilcox
2021-10-07  9:15 ` Kirill A. Shutemov
2021-10-07 10:06 ` Vlastimil Babka

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=YV4o9SxfYuLm1i4d@moria.home.lan \
    --to=kent.overstreet@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rientjes@google.com \
    --cc=willy@infradead.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).