Re: [BUG]thp: BUG at mm/huge_memory.c:1350

[Minchan Kim <minchan.kim@gmail.com>]

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@kvack.org.  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@kvack.org"> email@kvack.org </a>