Re: [PATCH 0/5] Light Fragmentation Avoidance V20

[Mel Gorman <mel@csn.ul.ie>]

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/