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 [EMAIL PROTECTED] ~]$ 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/ _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
