Re: PROBLEM: Remapping hugepages mappings causes kernel to return EINVAL

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

 



On 2017-10-23 13:42, Michal Hocko wrote:
I do not remember any such a request either. I can see some merit in the
described use case. It is not specific on why hugetlb pages are used for
the allocator memory because that comes with it own issues.

That is yet for the user to specify. As of now hugepages still require a special setup that not all people might have as of now - to my knowledge a kernel being compiled with CONFIG_TRANSPARENT_HUGEPAGE=y and a number of such pages being allocated either through the kernel boot line or through /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages. I'm deliberately ignoring 1-GiB pages here because those are only allocatable during boot, when no processes have been spawned and memory is still not fragmented.

My point is that I can see people not being too eager to support 1 GiB pages as of now unless for very specific use case. 2-MiB pages, on the other hand, shouldn't have those limitations anymore. User-space programs should be capable of allocating such pages without the need for the user to fiddle with nr_hugepages beforehand.

Some time ago I've written some code to detect TLB capabilities on my current testing CPU, those are the results:

[TLB] Instruction TLB: 2M/4M pages, fully associative, 8 entries
[TLB] Data TLB: 4 KByte pages, 4-way set associative, 64 entries
[TLB] Data TLB: 2 MByte or 4 MByte pages, 4-way set associative, 32 entries and a separate array with 1 GByte pages, 4-way set associative, 4 entries
[TLB] Instruction TLB: 4KByte pages, 8-way set associative, 64 entries
[STLB] Shared 2nd-Level TLB: 4 KByte/2MByte pages, 8-way associative, 1024 entries

With the knowledge that allocations in the Mebibyte range aren't uncommon at all nowadays and that one 2-MiB page eliminates the need for 512 4-KiB pages, we really should make advances towards treating 2-MiB pages just as casual as older pages. Allocators can still query if the kernel supports the specified page size, and specifying MAP_HUGETLB | MAP_HUGE_2MB would still be required in order to not break older programs, but from my perspective there is a lot to gain here.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[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