|| ||Andrew Morton <akpm-AT-linux-foundation.org> |
|| ||Mel Gorman <mel-AT-csn.ul.ie> |
|| ||Re: Performance degradation seen after using one list for hot/cold
|| ||Wed, 8 Jul 2009 14:29:46 -0700|
|| ||kamezawa.hiroyu-AT-jp.fujitsu.com, narayanan.g-AT-samsung.com,
|| ||Article, Thread
(cc stable, linux-kernel and linux-scsi)
> On Mon, 22 Jun 2009 11:06:32 +0100 Mel Gorman <firstname.lastname@example.org> 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.
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 email@example.com. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"firstname.lastname@example.org"> email@example.com </a>
to post comments)