Messages in this thread | | | Date | Mon, 12 May 2014 11:09:25 +0200 | From | Vlastimil Babka <> | Subject | Re: [PATCH v2 2/2] mm/compaction: avoid rescanning pageblocks in isolate_freepages |
| |
On 05/08/2014 07:28 AM, Joonsoo Kim wrote: > On Wed, May 07, 2014 at 02:09:10PM +0200, Vlastimil Babka wrote: >> The compaction free scanner in isolate_freepages() currently remembers PFN of >> the highest pageblock where it successfully isolates, to be used as the >> starting pageblock for the next invocation. The rationale behind this is that >> page migration might return free pages to the allocator when migration fails >> and we don't want to skip them if the compaction continues. >> >> Since migration now returns free pages back to compaction code where they can >> be reused, this is no longer a concern. This patch changes isolate_freepages() >> so that the PFN for restarting is updated with each pageblock where isolation >> is attempted. Using stress-highalloc from mmtests, this resulted in 10% >> reduction of the pages scanned by the free scanner. > > Hello, > > Although this patch could reduce page scanned, it is possible to skip > scanning fresh pageblock. If there is zone lock contention and we are on > asyn compaction, we stop scanning this pageblock immediately. And > then, we will continue to scan next pageblock. With this patch, > next_free_pfn is updated in this case, so we never come back again to this > pageblock. Possibly this makes compaction success rate low, doesn't > it?
Hm, you're right and thanks for catching that, but I think this is a sign of a worse and older issue than skipping a pageblock? When isolate_freepages_block() breaks loop due to lock contention, then isolate_freepages() (which called it) should also immediately quit its loop. Trying another pageblock in the same zone with the same zone->lock makes no sense here? If this is fixed, then the issue you're pointing out will also be fixed as next_free_pfn will still point to the pageblock where the break occured.
> Thanks. >
| |