Re: [PATCH RESEND 0/8] hugetlb: add demote/split page functionality

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

 



On 17.08.21 03:46, Andrew Morton wrote:
On Mon, 16 Aug 2021 17:46:58 -0700 Mike Kravetz <mike.kravetz@xxxxxxxxxx> wrote:

It really is a ton of new code.  I think we're owed much more detail
about the problem than the above.  To be confident that all this
material is truly justified?

The desired functionality for this specific use case is to simply
convert a 1G huegtlb page to 512 2MB hugetlb pages.  As mentioned

"Converting larger to smaller hugetlb pages can be accomplished today by
  first freeing the larger page to the buddy allocator and then allocating
  the smaller pages.  However, there are two issues with this approach:
  1) This process can take quite some time, especially if allocation of
     the smaller pages is not immediate and requires migration/compaction.
  2) There is no guarantee that the total size of smaller pages allocated
     will match the size of the larger page which was freed.  This is
     because the area freed by the larger page could quickly be
     fragmented."

These two issues have been experienced in practice.

Well the first issue is quantifiable.  What is "some time"?  If it's
people trying to get a 5% speedup on a rare operation because hey,
bugging the kernel developers doesn't cost me anything then perhaps we
have better things to be doing.

And the second problem would benefit from some words to help us
understand how much real-world hurt this causes, and how frequently.
And let's understand what the userspace workarounds look like, etc.

A big chunk of the code changes (aprox 50%) is for the vmemmap
optimizations.  This is also the most complex part of the changes.
I added the code as interaction with vmemmap reduction was discussed
during the RFC.  It is only a performance enhancement and honestly
may not be worth the cost/risk.  I will get some numbers to measure
the actual benefit.

If it really makes that much of a difference code/complexity wise, would it make sense to just limit denote functionality to the !vmemmap case for now?

--
Thanks,

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