lkml.org 
[lkml]   [2017]   [Nov]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] mm, compaction: direct freepage allocation for async direct compaction
On Wed, Nov 29, 2017 at 03:32:08PM +0900, Joonsoo Kim wrote:
> On Thu, Nov 23, 2017 at 02:08:43PM +0000, Mel Gorman wrote:
>
> > 3. Another reason a linear scanner was used was because we wanted to
> > clear entire pageblocks we were migrating from and pack the target
> > pageblocks as much as possible. This was to reduce the amount of
> > migration required overall even though the scanning hurts. This patch
> > takes MIGRATE_MOVABLE pages from anywhere that is "not this pageblock".
> > Those potentially have to be moved again and again trying to randomly
> > fill a MIGRATE_MOVABLE block. Have you considered using the freelists
> > as a hint? i.e. take a page from the freelist, then isolate all free
> > pages in the same pageblock as migration targets? That would preserve
> > the "packing property" of the linear scanner.
> >
> > This would increase the amount of scanning but that *might* be offset by
> > the number of migrations the workload does overall. Note that migrations
> > potentially are minor faults so if we do too many migrations, your
> > workload may suffer.
> >
> > 4. One problem the linear scanner avoids is that a migration target is
> > subsequently used as a migration source and leads to a ping-pong effect.
> > I don't know how bad this is in practice or even if it's a problem at
> > all but it was a concern at the time
>
> IIUC, this potential advantage for a linear scanner would not be the
> actual advantage in the *running* system.
>
> Consider about following worst case scenario for "direct freepage
> allocation" that "moved again" happens.
>

The immediate case should be ok as long as the migration source and the
pageblock a freepage is taken from is not the same pageblock. That might
mean that more pages from the freelist would need to be examined until
another pageblock was found.

>
> So, I think that "direct freepage allocation" doesn't suffer from such
> a ping-poing effect. Am I missing something?
>

The ping-pong effect I'm concerned with is that a previous migration
target is used as a migration source in the future. It's hard for that
situation to occur with two linear scanners but care is needed when
using direct freepage allocation.

--
Mel Gorman
SUSE Labs

\
 
 \ /
  Last update: 2017-11-29 15:14    [W:0.217 / U:3.636 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site