lkml.org 
[lkml]   [2016]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Suspicious error for CMA stress test
    From
    Date
    Am Freitag, den 18.03.2016, 21:58 +0100 schrieb Vlastimil Babka:
    > On 03/18/2016 03:42 PM, Lucas Stach wrote:
    > > Am Freitag, den 18.03.2016, 15:10 +0100 schrieb Vlastimil Babka:
    > >> On 03/17/2016 04:52 PM, Joonsoo Kim wrote:
    > >> > 2016-03-18 0:43 GMT+09:00 Vlastimil Babka <vbabka@suse.cz>:
    > >>
    > >> OK, here it is. Hanjun can you please retest this, as I'm not sure if you had
    > >> the same code due to the followup one-liner patches in the thread. Lucas, see if
    > >> it helps with your issue as well. Laura and Joonsoo, please also test and review
    > >> and check changelog if my perception of the problem is accurate :)
    > >>
    > >
    > > This doesn't help for my case, as it is still trying to merge pages in
    > > isolated ranges. It even tries extra hard at doing so.
    > >
    > > With concurrent isolation and frees going on this may lead to the start
    > > page of the range to be isolated merging into an higher order buddy page
    > > if it isn't already pageblock aligned, leading both test_pages_isolated
    > > and isolate_freepages to fail on an otherwise perfectly fine range.
    > >
    > > What I am arguing is that if a page is freed into an isolated range we
    > > should not try merge it with it's buddies at all, by setting max_order =
    > > order. If the range is isolated because want to isolate freepages from
    > > it, the work to do the merging is wasted, as isolate_freepages will
    > > split higher order pages into order-0 pages again.
    > >
    > > If we already finished isolating freepages and are in the process of
    > > undoing the isolation, we don't strictly need to do the merging in
    > > __free_one_page, but can defer it to unset_migratetype_isolate, allowing
    > > to simplify those code paths by disallowing any merging of isolated
    > > pages at all.
    >
    > Oh, I think understand now. Yeah, skipping merging for pages in isolated
    > pageblocks might be a rather elegant solution. But still, we would have to check
    > buddy's migratetype at order >= pageblock_order like my patch does, which is
    > annoying. Because even without isolated merging, the buddy might have already
    > had order>=pageblock_order when it was isolated.

    > So what if isolation also split existing buddies in the pageblock immediately
    > when it sets the MIGRATETYPE_ISOLATE on the pageblock? Then we would have it
    > guaranteed that there's no isolated buddy - a buddy candidate at order >=
    > pageblock_order either has a smaller order (so it's not a buddy) or is not
    > MIGRATE_ISOLATE so it's safe to merge with.
    >
    > Does that make sense?
    >
    This might increase the the overhead of isolation a lot. CMA is also
    used for small order allocations, so the work of splitting a whole
    pageblock to allocate a small number of pages out just to merge a lot of
    them again on unisolation might make this unattractive.

    My feeling is that checking the buddy migratetype for >=pageblock_order
    frees might be lower overhead, but I have no hard numbers to back this
    claim.

    Then on the other hand moving the work to isolation/unisolation affects
    only code paths that are expected to be quite slow anyways, doing the
    check in _free_one_page will affect everyone.

    Regards,
    Lucas

    \
     
     \ /
      Last update: 2016-03-22 16:21    [W:3.198 / U:0.164 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site