Kernel configuration options

[Bernardo Innocenti]

John Richard Moser wrote:

> YES.  You can mix and match your page sizes, have some pages 4MiB and 
> some 4KiB.  If a block of i.e. the heap is 4MiB long, the kernel can 
> technically relocate all 1024 involved pages so they're physically 
> contiguous and aligned to a 4MiB boundary, and then remap them as one 
> huge page.  It would have to handle an munmap() or brk() (shrinking) 
> call by breaking it back up; but it could be done.

There's only partial vm support for 4MB pages in Linux, and
only for special cases.

On a few systems, I get:

trinity:~# cat /proc/meminfo | grep Huge
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:     4096 kB
bender:~# cat /proc/meminfo | grep Huge
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
HugePages_Surp:      0
Hugepagesize:     2048 kB
[bernie at bombadil ~]$ cat /proc/meminfo | grep Huge
HugePages_Total:     0
HugePages_Free:      0
HugePages_Rsvd:      0
Hugepagesize:    16384 kB
daneel:~# cat /proc/meminfo  | grep Huge
(no output)

I wonder if huge pages are even used for anything?


> There's no reason with video memory sizes like 4M, 8M, 16M, 32M, 64M, 
> 256M, and these days even 512M that these kinds of mappings should use 
> 4KiB pages anymore.  Unlike the heap or anonymous mmap() segments, video 
> memory doesn't change size and doesn't eat physical memory (*cough*); 
> and unlike file-backed shared mmap() segments, you can't free up space 
> by evicting the contents from memory if nobody's using it.

It's probably not being done because of this feature is
very recent, and maybe immature.

-- 
 \___/
 |___|   Bernardo Innocenti - http://www.codewiz.org/
  \___\  One Laptop Per Child - http://www.laptop.org/