Re: 2.6.38 page_test regression

[Andrea Arcangeli <aarcange@redhat.com>]

On Fri, Apr 15, 2011 at 01:32:26AM +0200, Andrea Arcangeli wrote:
> On Thu, Apr 14, 2011 at 10:53:27PM +0100, Mel Gorman wrote:
> > On Thu, Apr 14, 2011 at 11:07:23PM +0300, raz ben yehuda wrote:
> > > bah. Mel is correct. I did mean page_test  ( in my defense it is in the
> > > msg ).
> > > Here some more information:
> > > 1. I manage to lower the regression to 2 sha1's:
> > >     	32dba98e085f8b2b4345887df9abf5e0e93bfc12 to
> > > 71e3aac0724ffe8918992d76acfe3aad7d8724a5. 
> > > 	though I had to remark wait_split_huge_page for the sake of
> > > compilation. up to 32dba98e085f8b2b4345887df9abf5e0e93bfc12 there is no
> > > regression.
> > > 
> > > 2. I booted 2.6.37-rc5 you gave me. same regression is there. 
> > 
> > Extremely long shot - try this patch.
> > 
> > diff --git a/mm/memory.c b/mm/memory.c
> > index c50a195..a39baaf 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -3317,7 +3317,7 @@ int handle_mm_fault(struct mm_struct *mm, struct vm_area_struct *vma,
> >  	 * run pte_offset_map on the pmd, if an huge pmd could
> >  	 * materialize from under us from a different thread.
> >  	 */
> > -	if (unlikely(__pte_alloc(mm, vma, pmd, address)))
> > +	if (unlikely(!pmd_present(*(pmd))) && __pte_alloc(mm, vma, pmd, address))

Actually reading this again this should be pmd_none. This is one
change I had to make across the board because for an tiny amount of
time during the pmd teardown I have to mark an pmd_trans_splitting pte
not present in order to flush it away from the 2m tlb before the 4k
tlb can be loaded (for errata), but when it's being splitted it's
definitely not null. Now it's not buggy because then __pte_alloc would
then check it against pmd_none, but it's not worth calling into
__pte_alloc if it's not pmd_none. It just makes it confusing when
everything has been updated to check pmd_none.

Just a nitpick of course (not even a bug).