| |||||||||||||
|
| |||||||||||||
Large pages, large blocks, and large problemsLarge pages, large blocks, and large problemsPosted Sep 20, 2007 12:55 UTC (Thu) by i3839 (subscriber, #31386)In reply to: Large pages, large blocks, and large problems by vblum Parent article: Large pages, large blocks, and large problems
Not really.
There is always a mapping made between the virtual addresses and the physical ones, so what's different is which physical pages are chosen. Choosing contiguous physical pages is harder and takes more time, but it doesn't give any advantages. Bringing the fragments together is done by mapping them to a contiguous virtual memory range.
Mapping to contiguous physical pages might be faster if the hardware supports (really) variable sized pages, but as far as I know none does.
Fragmentation doesn't slow things down, it only makes it harder to allocate chunks bigger than one pagesize.
The demand for bigger pagesizes comes from people who think it will reduce overhead for their workload, because everything that's done per page can be done less often. The main thing preventing this from working seamlessly is fragmentation.
(Log in to post comments)
|
|
||||||||||||