From: Andrew Morton <akpm@linux-foundation.org>
To: Mel Gorman <mel@csn.ul.ie>
Cc: kamezawa.hiroyu@jp.fujitsu.com, narayanan.g@samsung.com,
linux-mm@kvack.org, cl@linux-foundation.org,
kosaki.motohiro@jp.fujitsu.com, stable@kernel.org,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: Re: Performance degradation seen after using one list for hot/cold pages.
Date: Wed, 8 Jul 2009 14:29:46 -0700 [thread overview]
Message-ID: <20090708142946.83c40331.akpm@linux-foundation.org> (raw)
In-Reply-To: <20090622100632.GB3981@csn.ul.ie>
(cc stable, linux-kernel and linux-scsi)
> On Mon, 22 Jun 2009 11:06:32 +0100 Mel Gorman <mel@csn.ul.ie> wrote:
> [PATCH] page-allocator: Preserve PFN ordering when __GFP_COLD is set
>
> The page allocator tries to preserve contiguous PFN ordering when returning
> pages such that repeated callers to the allocator have a strong chance of
> getting physically contiguous pages, particularly when external fragmentation
> is low. However, of the bulk of the allocations have __GFP_COLD set as
> they are due to aio_read() for example, then the PFNs are in reverse PFN
> order. This can cause performance degration when used with IO
> controllers that could have merged the requests.
>
> This patch attempts to preserve the contiguous ordering of PFNs for
> users of __GFP_COLD.
Thanks.
I'll add the rather important text:
Fix a post-2.6.24 performance regression caused by
3dfa5721f12c3d5a441448086bee156887daa961 ("page-allocator: preserve PFN
ordering when __GFP_COLD is set").
This was a pretty major screwup.
This is why changing core MM is so worrisome - there's so much secret and
subtle history to it, and performance dependencies are unobvious and quite
indirect and the lag time to discover regressions is long.
Narayanan, are you able to quantify the regression more clearly? All I
have is "2 MBps lower" which isn't very useful. What is this as a
percentage, and with what sort of disk controller? Thanks.
--
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:[~2009-07-08 21:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-22 5:50 Performance degradation seen after using one list for hot/cold pages Narayanan Gopalakrishnan
2009-06-22 7:41 ` KAMEZAWA Hiroyuki
2009-06-22 10:06 ` Mel Gorman
2009-07-08 21:29 ` Andrew Morton [this message]
-- strict thread matches above, loose matches on Subject: below --
2009-06-22 11:32 Re: " NARAYANAN GOPALAKRISHNAN
2009-06-22 16:52 ` Mel Gorman
2009-06-23 0:06 ` KAMEZAWA Hiroyuki
2009-06-23 17:41 ` Christoph Lameter
2009-06-25 9:11 ` Minchan Kim
2009-06-29 9:15 ` 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=20090708142946.83c40331.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=cl@linux-foundation.org \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=kosaki.motohiro@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-scsi@vger.kernel.org \
--cc=mel@csn.ul.ie \
--cc=narayanan.g@samsung.com \
--cc=stable@kernel.org \
/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).