linux-kernel - Re: Performance degradation seen after using one list for hot/cold pages.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <20090708142946.83c40331.akpm@linux-foundation.org>
Date:	Wed, 8 Jul 2009 14:29:46 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Mel Gorman <mel@....ul.ie>
Cc:	kamezawa.hiroyu@...fujitsu.com, narayanan.g@...sung.com,
	linux-mm@...ck.org, cl@...ux-foundation.org,
	kosaki.motohiro@...fujitsu.com, stable@...nel.org,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: Performance degradation seen after using one list for hot/cold
 pages.

(cc stable, linux-kernel and linux-scsi)

> On Mon, 22 Jun 2009 11:06:32 +0100 Mel Gorman <mel@....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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/