From: Dave Chinner <david@fromorbit.com>
To: Mel Gorman <mel@csn.ul.ie>
Cc: xfs@oss.sgi.com, Alex Elder <aelder@sgi.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [RFC PATCH] fs,xfs: Use __GFP_MOVABLE for XFS buffers
Date: Fri, 10 Sep 2010 10:37:06 +1000 [thread overview]
Message-ID: <20100910003706.GC7032@dastard> (raw)
In-Reply-To: <20100909111131.GO29263@csn.ul.ie>
On Thu, Sep 09, 2010 at 12:11:32PM +0100, Mel Gorman wrote:
> Fragmentation avoidance in the kernel depends on reclaimable and movable
> allocations being marked-up at page allocation time. Reclaimable allocations
> refer to slab caches such as inode caches which can be reclaimed although
> not necessarily in a targetted fashion. Movable pages are those pages that
> can be moved to backing storage (during page reclaim) or migrated.
>
> When testing against XFS, it was noticed that large page allocation rates
> against XFS were far lower than expected in comparison to ext3. Investigation
> showed that buffer pages allocated by XFS are placed on the LRU but not
> marked __GFP_MOVABLE at allocation time.
>
> This patch updates xb_to_gfp() to specify __GFP_MOVABLE and is correct iff
> all pages allocated from a mask derived from xb_to_gfp() are guaranteed to
> be movable be it via page reclaim or page migration. It needs an XFS expert
> to make that determination but when applied, huge page allocation success
> rates are similar to those seen on tests backed by ext3.
>
> Signed-off-by: Mel Gorman <mel@csn.ul.ie>
I don't see any problems with this, but I don't think it's going to
be useful for very long given the work I'm doing on the XFS buffer
cache right now - converting it to caching buffers with a shrinker
traversed LRU for reclaim instead of using the page cache and hoping
reclaim doesn't trash the working set.
I'm hoping to have it done in time for the .37 merge window, so
adding __GFP_MOVEABLE now might not to even see a release....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
--
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>
next prev parent reply other threads:[~2010-09-10 0:37 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-09 11:11 [RFC PATCH] fs,xfs: Use __GFP_MOVABLE for XFS buffers Mel Gorman
2010-09-10 0:37 ` Dave Chinner [this message]
2010-09-10 8:33 ` Mel Gorman
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=20100910003706.GC7032@dastard \
--to=david@fromorbit.com \
--cc=aelder@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mel@csn.ul.ie \
--cc=xfs@oss.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;
as well as URLs for NNTP newsgroup(s).