linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Yu Zhao <yuzhao@google.com>
Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org,
	Jonathan Corbet <corbet@lwn.net>
Subject: Re: [Chapter One] THP zones: the use cases of policy zones
Date: Wed, 6 Mar 2024 04:33:55 +0000	[thread overview]
Message-ID: <ZefyM4I3RET745dZ@casper.infradead.org> (raw)
In-Reply-To: <CAOUHufZgEGHCU2JROxW2bEuc43RvSGSsyk4tZA7b0butsg=K0w@mail.gmail.com>

On Tue, Mar 05, 2024 at 10:51:20PM -0500, Yu Zhao wrote:
> On Thu, Feb 29, 2024 at 3:28 PM Matthew Wilcox <willy@infradead.org> wrote:
> > On Thu, Feb 29, 2024 at 11:34:33AM -0700, Yu Zhao wrote:
> > > Compared with the hugeTLB pool approach, THP zones tap into core MM
> > > features including:
> > > 1. THP allocations can fall back to the lower zones, which can have
> > >    higher latency but still succeed.
> > > 2. THPs can be either shattered (see Chapter Two) if partially
> > >    unmapped or reclaimed if becoming cold.
> > > 3. THP orders can be much smaller than the PMD/PUD orders, e.g., 64KB
> > >    contiguous PTEs on arm64 [1], which are more suitable for client
> > >    workloads.
> >
> > Can this mechanism be used to fully replace the hugetlb pool approach?
> > That would be a major selling point.  It kind of feels like it should,
> > but I am insufficiently expert to be certain.
> 
> This depends on the return value from htlb_alloc_mask(): if it's
> GFP_HIGHUSER_MOVABLE, then yes (i.e., 2MB hugeTLB folios on x86).
> Hypothetically, if users can have THPs as reliable as hugeTLB can
> offer, wouldn't most users want to go with the former since it's more
> flexible? E.g., core MM features like split (shattering) and reclaim
> in addition to HVO.

Right; the real question is what can we do to unify hugetlbfs and THPs.
The reservation ability is one feature that hugetlbfs has over THP and
removing that advantage gets us one step closer.

> > I'll read over the patches sometime soon.  There's a lot to go through.
> > Something I didn't see in the cover letter or commit messages was any
> > discussion of page->flags and how many bits we use for ZONE (particularly
> > on 32-bit).  Perhaps I'll discover the answer to that as I read.
> 
> There may be corner cases because of how different architectures use
> page->flags, but in general, this shouldn't be a big problem because
> we can have 6 zones (at most) before this series, and after this
> series, we can have 8 (at most). IOW, we need 3 bits regardless, in
> order to all existing zones.

On a 32-bit system, we'll typically only have four; DMA, NORMAL, HIGHMEM
and MOVABLE.  DMA32 will be skipped since it would match NORMAL, and
DEVICE is just not supported on 32-bit.


  reply	other threads:[~2024-03-06  4:34 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-29 18:34 [LSF/MM/BPF TOPIC] TAO: THP Allocator Optimizations Yu Zhao
2024-02-29 18:34 ` [Chapter One] THP zones: the use cases of policy zones Yu Zhao
2024-02-29 20:28   ` Matthew Wilcox
2024-03-06  3:51     ` Yu Zhao
2024-03-06  4:33       ` Matthew Wilcox [this message]
2024-02-29 23:31   ` Yang Shi
2024-03-03  2:47     ` Yu Zhao
2024-03-04 15:19   ` Matthew Wilcox
2024-03-05 17:22     ` Matthew Wilcox
2024-03-05  8:41   ` Barry Song
2024-03-05 10:07     ` Vlastimil Babka
2024-03-05 21:04       ` Barry Song
2024-03-06  3:05         ` Yu Zhao
2024-05-24  8:38   ` Barry Song
2024-11-01  2:35   ` Charan Teja Kalla
2024-11-01 16:55     ` Yu Zhao
2024-02-29 18:34 ` [Chapter Two] THP shattering: the reverse of collapsing Yu Zhao
2024-02-29 21:55   ` Zi Yan
2024-03-03  1:17     ` Yu Zhao
2024-03-03  1:21       ` Zi Yan
2024-06-11  8:32   ` Barry Song
2024-02-29 18:34 ` [Chapter Three] THP HVO: bring the hugeTLB feature to THP Yu Zhao
2024-02-29 22:54   ` Yang Shi
2024-03-01 15:42     ` David Hildenbrand
2024-03-03  1:46     ` Yu Zhao
2024-02-29 18:34 ` [Epilogue] Profile-Guided Heap Optimization and THP fungibility Yu Zhao
2024-03-05  8:37 ` [LSF/MM/BPF TOPIC] TAO: THP Allocator Optimizations Barry Song
2024-03-06 15:51 ` Johannes Weiner
2024-03-06 16:40   ` Zi Yan
2024-03-13 22:09   ` Kaiyang Zhao
2024-05-15 21:17 ` Yu Zhao
2024-05-15 21:52   ` Yu Zhao

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=ZefyM4I3RET745dZ@casper.infradead.org \
    --to=willy@infradead.org \
    --cc=corbet@lwn.net \
    --cc=linux-mm@kvack.org \
    --cc=lsf-pc@lists.linux-foundation.org \
    --cc=yuzhao@google.com \
    /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).