| |||||||||||||
Large pages, large blocks, and large problemsLarge pages, large blocks, and large problemsPosted Sep 19, 2007 18:39 UTC (Wed) by eSk (subscriber, #45221)In reply to: Large pages, large blocks, and large problems by james Parent article: Large pages, large blocks, and large problems
I've never understood Linus' aversion against general support for superpages. He always seems to make use of this argument that it does not matter (performance or otherwise). However, at the OSDI '02 Navarro published a very thorough analysis of how superpage support helped performance by increasing TLB coverage [1]. The page sizes used were 8KB, 64KB, 512KB, and 4MB and the whole thing was implemented in FreeBSD. He also described the techiques used for promoting and demoting superpages (i.e., automatically converting beween different page sizes as needed). He didn't even talk about other advantages of using superpages (e.g., for supporting large blocks), but the results he obtained were still impressive. BTW, another side effect of using superpages is that you tend to get better cache utilization because you automatically get a cache coloring effect by using the larger page sizes.
[1] Navarro et al., "Practical, transparent operating system support for superpages", OSDI '02.
(Log in to post comments)
Large pages, large blocks, and large problems Posted Sep 20, 2007 0:54 UTC (Thu) by sayler (guest, #3164) [Link] "This system is implemented in FreeBSD on the Alpha architecture," The Alpha has (had?) good support for higher-order page allocation at the hardware level that is not currently present in current-gen Intel and AMD chips.
Large pages, large blocks, and large problems Posted Sep 20, 2007 11:13 UTC (Thu) by eSk (subscriber, #45221) [Link] Sure. Running these experiments on any x86-lineage chip would obviously not work (except perhaps in a simulator) because of lacking the wider range of page sizes. The point I was trying to make is that Linus argues strongly against the usefulness of any page size above 4K/8K, except for some special cases where very large superpages are used explicitly.
Large pages, large blocks, and large problems Posted Sep 27, 2007 13:43 UTC (Thu) by anton (guest, #25547) [Link] Running these experiments on any x86-lineage chip would obviously not work (except perhaps in a simulator) because of lacking the wider range of page sizes.On a machine that has plenty of memory for what's running on it, a variation of the Navarro approach might still be useful even on an IA32/AMD64 machine. The OS would rarely feel enough memory pressure to consider splitting a large page. Also, since Linux also supports architectures that have finer-grained page size steps, it should not look just at what IA32/AMD64 support. And once a popular OS like Linux supports it, the hardware designers at Intel and AMD can better justify adding additional page sizes to their hardware.
Large pages, large blocks, and large problems Posted Sep 20, 2007 13:42 UTC (Thu) by zlynx (subscriber, #2285) [Link] Intel's Itanium supports page sizes in all powers of 2 from 4K to 256M. That's a current-gen Intel chip.
Large pages, large blocks, and large problems Posted Sep 21, 2007 14:58 UTC (Fri) by jamesh (guest, #1159) [Link] It may be present generation, but any software developer who made decisions based on the assumption of increased adoption of Itanium is crazy.
Large pages, large blocks, and large problems Posted Sep 21, 2007 17:21 UTC (Fri) by vonbrand (subscriber, #4458) [Link] Current generation intel chips are clones of AMD64.
Large pages, large blocks, and large problems Posted Sep 21, 2007 18:33 UTC (Fri) by zlynx (subscriber, #2285) [Link] Not really, or they would have included more of the good parts like the IOMMU and memory controller.
|
|||||||||||||