Re: [PATCH v8 00/10] Multi-size THP for anonymous memory

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

 



On 04.12.23 11:20, Ryan Roberts wrote:
Hi All,

A new week, a new version, a new name... This is v8 of a series to implement
multi-size THP (mTHP) for anonymous memory (previously called "small-sized THP"
and "large anonymous folios"). Matthew objected to "small huge" so hopefully
this fares better.

The objective of this is to improve performance by allocating larger chunks of
memory during anonymous page faults:

1) Since SW (the kernel) is dealing with larger chunks of memory than base
    pages, there are efficiency savings to be had; fewer page faults, batched PTE
    and RMAP manipulation, reduced lru list, etc. In short, we reduce kernel
    overhead. This should benefit all architectures.
2) Since we are now mapping physically contiguous chunks of memory, we can take
    advantage of HW TLB compression techniques. A reduction in TLB pressure
    speeds up kernel and user space. arm64 systems have 2 mechanisms to coalesce
    TLB entries; "the contiguous bit" (architectural) and HPA (uarch).

This version changes the name and tidies up some of the kernel code and test
code, based on feedback against v7 (see change log for details).

By default, the existing behaviour (and performance) is maintained. The user
must explicitly enable multi-size THP to see the performance benefit. This is
done via a new sysfs interface (as recommended by David Hildenbrand - thanks to
David for the suggestion)! This interface is inspired by the existing
per-hugepage-size sysfs interface used by hugetlb, provides full backwards
compatibility with the existing PMD-size THP interface, and provides a base for
future extensibility. See [8] for detailed discussion of the interface.

This series is based on mm-unstable (715b67adf4c8).

I took a look at the core pieces. Some things might want some smaller tweaks, but nothing that should stop this from having fun in mm-unstable, and replacing the smaller things as we move forward.

--
Cheers,

David / dhildenb





[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