linux-kernel - Re: [RFC PATCH 0/2] avoid external fragmentation related to migration fallback

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20160201135351.GB8337@techsingularity.net>
Date:	Mon, 1 Feb 2016 13:53:51 +0000
From:	Mel Gorman <mgorman@...hsingularity.net>
To:	Vlastimil Babka <vbabka@...e.cz>
Cc:	ChengYi He <chengyihetaipei@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Michal Hocko <mhocko@...e.com>,
	David Rientjes <rientjes@...gle.com>,
	Joonsoo Kim <js1304@...il.com>,
	Yaowei Bai <bywxiaobai@....com>,
	Xishi Qiu <qiuxishi@...wei.com>,
	Alexander Duyck <alexander.h.duyck@...hat.com>,
	"'Kirill A . Shutemov'" <kirill.shutemov@...ux.intel.com>,
	Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/2] avoid external fragmentation related to
 migration fallback

On Fri, Jan 29, 2016 at 10:03:52PM +0100, Vlastimil Babka wrote:
> > Since the root cause is that fallbacks might frequently split order-2
> > and order-3 pages of the other migration types. This patch tweaks
> > fallback mechanism to avoid splitting order-2 and order-3 pages. while
> > fallbacks happen, if the largest feasible pages are less than or queal to
> > COSTLY_ORDER, i.e. 3, then try to select the smallest feasible pages. The
> > reason why fallbacks prefer the largest feasiable pages is to increase
> > fallback efficiency since fallbacks are likely to happen again. By
> > stealing the largest feasible pages, it could reduce the oppourtunities
> > of antoher fallback. Besides, it could make consecutive allocations more
> > approximate to each other and make system less fragment. However, if the
> > largest feasible pages are less than or equal to order-3, fallbacks might
> > split it and make the upcoming order-3 page allocations fail.
> 
> In theory I don't see immediately why preferring smaller pages for
> fallback should be a clear win. If it's Unmovable allocations stealing
> from Movable pageblocks, the allocations will spread over larger areas
> instead of being grouped together. Maybe, for Movable allocations
> stealing from Unmovable allocations, preferring smallest might make
> sense and be safe, as any extra fragmentation is fixable bycompaction.

I strongly agree that spreading the fallback allocations over a larger
area is likely to have a negative impact. Given the age of the kernel
being tested, it would make sense to either rebase or at the very last
backport the patches that affect watermark calculations and the
treatment of high-order pages.

-- 
Mel Gorman
SUSE Labs