From: Mel Gorman <mel@csn.ul.ie>
To: Paul Jackson <pj@sgi.com>
Cc: linux-mm@kvack.org, mingo@elte.hu,
lhms-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org,
nickpiggin@yahoo.com.au
Subject: Re: [PATCH 0/5] Light Fragmentation Avoidance V20
Date: Wed, 16 Nov 2005 01:34:51 +0000 (GMT) [thread overview]
Message-ID: <Pine.LNX.4.58.0511160122040.8470@skynet> (raw)
In-Reply-To: <20051115145451.671a29ec.pj@sgi.com>
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, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
prev parent reply other threads:[~2005-11-16 1:34 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-15 16:49 Mel Gorman
2005-11-15 16:49 ` [PATCH 1/5] Light Fragmentation Avoidance V20: 001_antidefrag_flags Mel Gorman
2005-11-15 23:00 ` Paul Jackson
2005-11-15 23:04 ` Randy.Dunlap
2005-11-16 1:36 ` Mel Gorman
2005-11-20 14:45 ` [Lhms-devel] " Paul Jackson
2005-11-15 16:49 ` [PATCH 2/5] Light Fragmentation Avoidance V20: 002_usemap Mel Gorman
2005-11-15 23:36 ` Andi Kleen
2005-11-16 1:43 ` Mel Gorman
2005-11-16 1:52 ` Andi Kleen
2005-11-16 2:07 ` Mel Gorman
2005-11-22 10:13 ` Andy Whitcroft
2005-11-22 10:19 ` Mel Gorman
2005-11-22 10:22 ` Andi Kleen
2005-11-22 10:35 ` Mel Gorman
2005-11-22 10:48 ` KAMEZAWA Hiroyuki
2005-11-22 19:40 ` Mel Gorman
2005-11-22 10:54 ` KAMEZAWA Hiroyuki
2005-11-22 11:10 ` Mel Gorman
2005-11-22 11:35 ` Mel Gorman
2005-11-15 16:50 ` [PATCH 3/5] Light Fragmentation Avoidance V20: 003_fragcore Mel Gorman
2005-11-16 2:35 ` KAMEZAWA Hiroyuki
2005-11-16 10:42 ` Mel Gorman
2005-11-15 16:50 ` [PATCH 4/5] Light Fragmentation Avoidance V20: 004_percpu Mel Gorman
2005-11-15 23:24 ` Paul Jackson
2005-11-16 1:37 ` Mel Gorman
2005-11-15 16:50 ` [PATCH 5/5] Light Fragmentation Avoidance V20: 005_configurable Mel Gorman
2005-11-15 23:39 ` Andi Kleen
2005-11-16 1:47 ` Mel Gorman
2005-11-15 22:54 ` [PATCH 0/5] Light Fragmentation Avoidance V20 Paul Jackson
2005-11-16 1:34 ` Mel Gorman [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0511160122040.8470@skynet \
--to=mel@csn.ul.ie \
--cc=lhms-devel@lists.sourceforge.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@elte.hu \
--cc=nickpiggin@yahoo.com.au \
--cc=pj@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox