Re: [Lsf-pc] [LSF/MM/BPF TOPIC]mTHP reliable allocation and reclamation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 16, 2024 at 1:50 AM Yang Shi <shy828301@xxxxxxxxx> wrote:
>
> On Tue, May 14, 2024 at 8:45 PM Barry Song <21cnbao@xxxxxxxxx> wrote:
> >
> > On Sat, May 11, 2024 at 8:33 AM Yu Zhao <yuzhao@xxxxxxxxxx> wrote:
> > >
> > > On Fri, May 10, 2024 at 8:25 AM Michal Hocko <mhocko@xxxxxxxx> 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





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux