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.
__M1___F1_________________F2__F3___
M: migration source page (the number denotes the ID of the page)
F: freepage (the number denotes the sequence in the freelist of the buddy)
_: other pages
migration scanner: move from left to right.
If migration happens with "direct freepage allocation", memory state
will be changed to:
__F?___M1_________________F2__F3___
And then, please assume that there is an another movable allocation
before another migration. It's reasonable assumption since there are
really many movable allocations in the *running* system.
__F?___M1_________________M2__F3___
If migration happens again, memory state will be:
__F?___F?_________________M2__M1___
M1 is moved twice and overall number of migration is two.
Now, think about a linear scanner. With the same scenario,
memory state will be as following.
__M1___F1_________________F2__F3___
__F?___F1_________________F2__M1___
__F?___M2_________________F2__M1___
__F?___F?_________________M2__M1___
Although "move again" doesn't happen in a linear scanner, final memory
state is the same and the same number of migration happens.
So, I think that "direct freepage allocation" doesn't suffer from such
a ping-poing effect. Am I missing something?
Thanks.
From 1585354850762740474@xxx Tue Nov 28 23:36:43 +0000 2017
X-GM-THRID: 1584777147397009876
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread