On Fri, Jan 21, 2011 at 07:14:42PM +0100, Andrea Arcangeli wrote: > On Sat, Jan 22, 2011 at 02:58:43AM +0900, Minchan Kim wrote: > > I tested it again with some printk and I knew why it is out of memory. > > > > do_page_fault(for write) > > -> do_huge_pmd_anonymous_page > > -> alloc_hugepage_vma > > > > Above is repeated by almost 400 times. It means 2M * 400 = 800M usage in my 2G system. > > Fragement can cause reclaim. > > Interesting one is that above is repeated by same faulty address of same process as looping. > > > > Apparently, do_huge_pmd_anonymous_page maps pmd to entry. > > Nonetheless, page faults are repeated by same address. > > It seems set_pmd_at is nop. > > > > Do you have any idea? > > Well clearly 32bit x86 wasn't well tested... Maybe we should > temporarily disable the config option on x86 32bit. > > > Sometime Xorg, Sometime kswapd, Sometime plymouthd, Sometime fsck. > > That's good. So the most likely explanation of that BUG_ON you hit, is > the same bug that causes do_huge_pmd_anonymous_page to flood on the > same address (clearly if CPU can't solve the TLB miss using the > hugepmd, the rmap walk of split_huge_page will also fail to find the > page in the hugepmd, so it makes perfect sense). > > That BUG_ON is by far my worst nightmare (that rmap walk of > split_huge_page must be as accurate as the > remove_migration_ptes/rmap_walk of migrate, it can't miss a hugepmd or > it'll be trouble, just like remove_migration_ptes/rmap_walk can't miss > a pte or it'll be trouble) and as far as common code is concerned I > had zero outstanding problems with it for a long time already, so > given your early debug info, I'm already optimistic and relieved that > 64bit is not affected by this and this isn't a generic common code > issue and the most likely explanation is some silly arch specific bug > that sets the pmd wrong and affects the page fault too (not just the > rmap walk). > > I'll try to reproduce. Checking the pagetable layout of the process at > the second page fault in the same address sounds good start to figure > out what's wrong on x86_32. Good news. If PSA is enable, it works well until now. Thanks for the good and interesting feature :) > > Thanks a lot for the help! > Andrea -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>