Messages in this thread | | | Date | Wed, 16 Nov 2005 01:34:51 +0000 (GMT) | From | Mel Gorman <> | Subject | Re: [PATCH 0/5] Light Fragmentation Avoidance V20 |
| |
On Tue, 15 Nov 2005, Paul Jackson wrote:
> I'm sure you've stated this before, but could you repeat it? > > What's the driving motivation for this, and what's the essential > capability required? >
For me, the ultimate aim is the transparent support of huge pages which would be a general benefit to any application that uses large amounts of address space or uses their address space sparsely. Low fragmentation is a prerequisite before you even start trying. Patches have been submitted for the demand paging of huge pages but obviously more is needed. This patchset should help the demand allocation of huge pages.
Other benefits are;
1. Benefits hotplug on some architectures, particularly ppc64 (fringe benefit) 2. HPC jobs that need to reset a system to a state with large pages available without rebooting the system benefit from this are likely to get their huge pages if they stop all running processes, dd a large file from /dev/zero and delete it again (fringe benefit) 3. Lower fragmentation means the per-cpu allocation is likely to be able to allocate pages in large batches avoiding multiple calls to the allocator. Jobs that are cache sensitive may benefit if they tend to fault their address space in chunks as they get pages that are contiguous in physical and virtual memoet (general benefit, patch available) 4. Prezeroing pages in large batches becomes a lot more feasible (general benefit, needs patch that does not regress performance) 5. Potentially reduces the blocks used for scatter/gather IO. In an earlier thread, it was noted that Windows is much better at providing large pages for DMA than Linux is (potential benefit, haven't measured it)
Think that covers the main points. Someone will chime in if I missed something important.
Lastly, benchmarks on my testbed show the patches to be as fast or faster than the standard allocator. Benchmark results that show the contrary are missing.
-- Mel Gorman Part-time Phd Student Java Applications Developer University of Limerick IBM Dublin Software Lab - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |