[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.1812211413460.219499@chino.kir.corp.google.com>
Date: Fri, 21 Dec 2018 14:15:05 -0800 (PST)
From: David Rientjes <rientjes@...gle.com>
To: Mel Gorman <mgorman@...hsingularity.net>
cc: Vlastimil Babka <vbabka@...e.cz>,
Andrea Arcangeli <aarcange@...hat.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Michal Hocko <mhocko@...nel.org>, ying.huang@...el.com,
s.priebe@...fihost.ag,
Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
alex.williamson@...hat.com, lkp@...org, kirill@...temov.name,
Andrew Morton <akpm@...ux-foundation.org>,
zi.yan@...rutgers.edu
Subject: Re: [LKP] [mm] ac5b2c1891: vm-scalability.throughput -61.3%
regression
On Fri, 14 Dec 2018, Mel Gorman wrote:
> > In other words, I think there is a lot of potential stranding that occurs
> > for both scanners that could otherwise result in completely free
> > pageblocks. If there a single movable page present near the end of the
> > zone in an otherwise fully free pageblock, surely we can do better than
> > the current implementation that would never consider this very easy to
> > compact memory.
> >
>
> While it's somewhat premature, I posted a series before I had a full set
> of results because it uses free lists to reduce searches and reduces
> inference between multiple scanners. Preliminary results indicated it
> boosted allocation success rates by 20%ish, reduced migration scanning
> by 99% and free scanning by 27%.
>
Always good to have code to look at, I'll take a closer look. I've
unfortunately been distracted with other kernel issues lately :/
Powered by blists - more mailing lists