Re: [LSF/MM/BPF TOPIC] Hugetlb Unifications

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

 



On Thu, Feb 22, 2024 at 12:36:40PM -0800, Frank van der Linden wrote:
> To me, it makes sense to have hugetlb pages themselves to just be
> large folios as much as possible.

Well, they are.  That isn't the concern:

$ git grep -c 'struct page' mm/hugetlb.c fs/hugetlbfs
fs/hugetlbfs/inode.c:5
mm/hugetlb.c:30
$ git grep -c 'struct folio' mm/hugetlb.c fs/hugetlbfs
fs/hugetlbfs/inode.c:10
mm/hugetlb.c:97

(further patches to convert pages to folios are welcome)

> On top of that, there could be a
> notion of physical memory pools with certain properties. The
> properties can be things like: size, evictability, migratability,
> possibly persistence across reboots, maybe "should not be in the
> direct map", like memfd_secret. hugetlbfs then could be expressed as a
> filesystem on top of a pool of, for example, 1G non-evictable pages.
> The pools themselves could have a memfd-like interface (or use memfd
> itself), and could also be used to hook in to things like KVM
> guestmemfd.
> 
> So yes, that would be a hugetlb v2, but mainly as a backward
> compatible layer on top of something more generic.

"Those who do not understand what hugetlbfs provides are condemned to
reinvent it badly".  We're really going to miss Mike this year.

The most important thing (to my mind) that it provides is shared page
tables.  It does it badly, hence the mshare proposal.  I don't think
we can make progress on a hugetlbfs2 until we have some mechanism in
the MM to share page tables (as using hugetlbfs2 will regress Certain
Important Workloads that pay my salary).

Another piece of the puzzle is reserved pages.  I have not investigated
this area at all, and so I don't know if the current mechanism in
hugetlbfs is a good one, how it could be hoisted to the MM layer, or
reimplemented in a hugetlbfs2.  Maybe this is where your mshare idea
comes in.

Peter's patches have been focused on removing some of the special casing
of hugetlbfs in the generic MM.  I think this is a great idea!  While I
haven't been actively reviewing those patches as they often touch areas
I'm not an expert in, I'm in favour of them going in.




[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