lkml.org 
[lkml]   [2014]   [May]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v2 2/2] mm/compaction: avoid rescanning pageblocks in isolate_freepages
    On Mon, May 12, 2014 at 11:09:25AM +0200, Vlastimil Babka wrote:
    > 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.
    >

    Yes. It can be fixed by your approach. :)

    Thanks.


    \
     
     \ /
      Last update: 2014-05-13 04:01    [W:4.593 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site