Re: [RFC PATCH 0/5] compaction: changing initial position of scanners

[Vlastimil Babka]

On 02/03/2015 07:49 AM, Joonsoo Kim wrote:
> On Mon, Jan 19, 2015 at 11:05:15AM +0100, Vlastimil Babka wrote:
> 
> Hello,
> 
> I don't have any elegant idea, but, have some humble opinion.
> 
> The point is that migrate scanner should scan whole zone.
> Although your pivot approach makes some sense and it can scan whole zone,
> it could cause back and forth migration in a very short term whenever
> both scanners get toward and passed each other.

I don't understand the scenario you suggest? The scanners don't overlap in any
single run, that doesn't change. If they meet, compaction terminates. They can
"overlap" if you compare the current run with previous run, after pivot change.
The it's true that e.g. migration scanner will operate on pageblocks where the
free scanner has operated on previously. But pivot changes are only done after
the full defer cycle, which is not short term.

> I think that if we permit
> overlap of scanner, we don't need to adhere to reverse linear scanning
> in freepage scanner since reverse liner scan doesn't prevent back and
> forth migration from now on.

I believe that we still don't permit overlap, but anyway...

> There are two solutions on this problem.
> One is that free scanner scans pfn in same direction where migrate scanner
> goes with having proper interval.
> 
> |=========================|
> MMM==>  <Interval>  FFF==>
> 
> Enough interval guarantees to prevent back and forth migration,
> at least, in a very short period.

That would depend on the termination criteria and what to do after restart.
You would have to terminate as soon as one scanner approaches the position where
the other started. Otherwise you overlap and migrate back in a single run. So
you terminate and that will typically mean one of the scanners did not finish
its part fully, so there are pageblocks scanned by neither one. You could adjust
the interval to find the optimal one. But you shouldn't do it immediately next
run, as that would overlap the previous run too soon. Or maybe adjust it only a
little... I don't know if that's simpler than my approach, it seems more quirky.

> Or, we could make free scanner totally different with linear scan.
> Linear scanning to get freepage wastes much time if system memory
> is really big and most of it is used. If we takes freepage from the
> buddy, we can eliminate this scanning overhead. With additional
> logic, that is, comparing position of freepage with migrate scanner
> and selectively taking it, we can avoid back and forth migration
> in a very short period.

I think the metric we should be looking is the ration between free pages scanned
and migrate pages scanned. It's true that after this series in the
allocate-as-thp scenario, it was more than 10 in the first run after reboot.
So maybe it could be more efficient to search the buddy lists. But then again,
when to terminate in this case? The free lists are changing continuously. And to
compare position, you also need to predict how much the migrate scanner will
progress in the single run, because you don't want to take pages from there.

> Thanks.
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/