[lkml]   [2010]   [Apr]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 04/14] mm,migration: Allow the migration of PageSwapCache pages
    On Mon, Apr 26, 2010 at 11:11:03PM +0100, Mel Gorman wrote:
    > Migration isn't holding the mmap_sem for write, for read or the pagetable
    > lock. It locks the page, unmaps it, puts a migration PTE in place that looks
    > like a swap entry, copies it and remaps it under the pagetable lock. At no
    > point does it hold the mmap_sem, but it needs to be sure it finds all the
    > migration pte it created. Because there are multiple anon_vma's, the locking
    > is tricky and unclear. I have one patch that locks the anon_vmas as it finds
    > them but is prepared to start over in the event of contention.

    split_huge_page has the exact same requirements, except it is more
    strict and it will stop zap_page_range and count that the same number
    of pmds it marked as splitting are found again later.

    Also note migration has the same "ordering" requirements for
    anon_vma_link during fork, new vmas have to be appended at the end or
    migration will choke (not going into the details of why, but I can if
    you want). This should be safe in new anon-vma code as I already
    pointed out this requirement to Rik for split_huge_page to be safe too.

    I never tested split_huge_page on the fixed new anon-vma code (before
    the latest fixes so with rc4 or so, I only know before the latest
    fixes it was triggering BUG_ON in split_huge_page as I've enough
    bug-on in there to be sure if split_huge_page doesn't BUG_ON, it's
    safe). I need to retry with the new anon-vma code... split_huge_page
    never showed anything wrong with the 2.6.33 code that I'm running on
    to reduce the variables in the equation.

    > The second appears to be migration ptes that get copied during fork().
    > This is easier to handle.

    And this is also where the requirement that new vmas are added to the
    end of the anon-vma lists comes from.

    > I'm testing two patches at the moment and after 8 hours have seen no problem
    > even though the races are being detected (and handled). If it survives the
    > night, I'll post them.

    I run again the same kernel as before and I reproduced the crash in
    migration_entry_wait swapops.h (page not locked) just once when I
    posted the stack trace and never again. I wanted to compare stack
    traces and see if it happens again. But that bug in
    migration_entry_wait can't be related to the new anon-vma code because
    I've backed it out from aa.git. Still you've to figure out if your
    patch is fixing a real bug.

    I'm just pointing out if there's a bug in anon-vma
    vma_adjust/expand_downards is unrelated to the crash in swapops.h
    migration_entry_wait. And obviously it's not either a bug in
    transparent hugepage code, as you also reproduced the same crash
    without using aa.git only with v8.

    We need to fix the swapops.h bug with maximum priority... (and of
    course the anon-vma bug too if it exists).

    Other than that swapops.h in migrate that you can also reproduce with
    only mainline + memory compaction v8, I had zero other problems with
    current aa.git.

     \ /
      Last update: 2010-04-27 00:31    [W:0.021 / U:11.036 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site