From: Barry Song <21cnbao@gmail.com>
To: Yang Shi <shy828301@gmail.com>
Cc: Yu Zhao <yuzhao@google.com>, Michal Hocko <mhocko@suse.com>,
Matthew Wilcox <willy@infradead.org>,
Linux-MM <linux-mm@kvack.org>,
lsf-pc@lists.linux-foundation.org
Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC]mTHP reliable allocation and reclamation
Date: Thu, 16 May 2024 06:14:15 +1200 [thread overview]
Message-ID: <CAGsJ_4yyNpokEMOc1nuRy4+vKmXJ_HMwvuycS7RET8HaRwsouw@mail.gmail.com> (raw)
In-Reply-To: <CAHbLzkpUOfdLU0qOEEODPZ=PWfFZ+CBO4+4XjKyR9ampB0K4tQ@mail.gmail.com>
On Thu, May 16, 2024 at 1:50 AM Yang Shi <shy828301@gmail.com> wrote:
>
> On Tue, May 14, 2024 at 8:45 PM Barry Song <21cnbao@gmail.com> wrote:
> >
> > On Sat, May 11, 2024 at 8:33 AM Yu Zhao <yuzhao@google.com> wrote:
> > >
> > > On Fri, May 10, 2024 at 8:25 AM Michal Hocko <mhocko@suse.com> wrote:
> > > >
> > > > On Fri 10-05-24 14:42:07, Barry Song wrote:
> > > > [...]
> > > > > I'm completely open to discussing both topics in the same TAO session.
> > > > > Having a separate session isn't important to me at all.
> > > >
> > > > If we happen to still have some topics uncovered we can schedule a
> > > > follow up slot.
> > >
> > > Thanks, Michal.
> > >
> > > Barry, you are very welcome to present your alternative approach in
> > > the same session.
> > >
> > > In fact, it seems that we both independently explored this
> > > pageblock-based approach. I did share our design with a few folks and
> > > explained why we put it on the back burner and have been focusing on
> > > the zone-based approach since then.
> > >
> > > Let me attach the deck that outlines our design, hopefully, we'll have
> > > enough time to cover some of its ideas if there is enough interest.
> >
> > Thank you. I'm also attaching our findings regarding mTHP allocation &
> > reclamation fallback, along with our approach and observations on running
> > TAO on Pixel 6.
> >
> > From deploying mTHP on numerous phones, I've learned that I'm not keen
> > on using dedicated page blocks for mTHP. Instead, I prefer the virtual zone
> > approach due to the folio size conflict in a single LRU. Further details are
> > available in the attached PDF.
>
> I'd like to know what page sizes were enabled for your test? A single
> page size, for example, 64K, or all possible page sizes?
A single page size - 64K. In my case, I doubt that enabling all
conceivable page sizes would improve performance, as user space may
have its own unique patterns for operations like MADV_DONTNEED. Since
much of the memory is likely allocated to the heap, enabling all sizes
could lead to numerous fragments within these heap VMAs.
Conversely, without a readahead-like mechanism, allocating large
folio sizes might result in portions of memory being seldom or never
used. Considering that 64K is one of the base page sizes for ARM hardware,
it strikes a balance between being adequately sized and not overly large.
>
> >
> > Best regards
> > Barry
Thanks
Barry
next prev parent reply other threads:[~2024-05-15 18:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-10 2:22 [LSF/MM/BPF TOPIC]mTHP reliable allocation and reclamation Barry Song
2024-05-10 2:31 ` Matthew Wilcox
2024-05-10 2:42 ` Barry Song
2024-05-10 14:25 ` [Lsf-pc] " Michal Hocko
2024-05-10 20:33 ` Yu Zhao
2024-05-15 2:42 ` Barry Song
2024-05-15 10:21 ` Karim Manaouil
2024-05-15 10:59 ` Yu Zhao
2024-05-15 13:50 ` Yang Shi
2024-05-15 18:14 ` Barry Song [this message]
2024-05-10 21:18 ` Yang Shi
2024-05-14 9:20 ` Barry Song
2024-05-15 13:49 ` Yang Shi
2024-05-15 19:25 ` Barry Song
2024-05-15 21:41 ` Yang Shi
2024-05-15 22:15 ` Barry Song
2024-05-15 23:41 ` Matthew Wilcox
2024-05-16 0:25 ` Barry Song
2024-05-16 3:19 ` Gao Xiang
2024-05-16 6:57 ` Barry Song
2024-05-16 7:07 ` Gao Xiang
2024-05-22 21:43 ` David Hildenbrand
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=CAGsJ_4yyNpokEMOc1nuRy4+vKmXJ_HMwvuycS7RET8HaRwsouw@mail.gmail.com \
--to=21cnbao@gmail.com \
--cc=linux-mm@kvack.org \
--cc=lsf-pc@lists.linux-foundation.org \
--cc=mhocko@suse.com \
--cc=shy828301@gmail.com \
--cc=willy@infradead.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 read-only IMAP folder(s) and NNTP newsgroup(s).