Date: Tue, 16 Mar 2004 11:32:09 +0900 (JST)
Message-Id: <20040316.113209.63031370.taka@valinux.co.jp>
To: ak@suse.de
Cc: n-yoshida@pst.fujitsu.com, raybry@sgi.com, linux-kernel@vger.kernel.org,
       lse-tech@lists.sourceforge.net, linux-ia64@vger.kernel.org
Subject: Re: Hugetlbpages in very large memory machines.......
From: Hirokazu Takahashi <taka@valinux.co.jp>
In-Reply-To: <20040316015401.GF9931@wotan.suse.de>
References: <20040313.135638.78732994.taka@valinux.co.jp>
	<JP20040316093003.3103921@pst.fujitsu.com>
	<20040316015401.GF9931@wotan.suse.de>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 995
Lines: 31

Hello,

> > +   pte = huge_pte_alloc(mm, address);
> > +   set_huge_pte(mm, vma, page, pte, vma->vm_flags & VM_WRITE);
> 
> This looks broken. Another CPU could have raced to the same fault
> and already added an PTE here. You have to handle that.
> 
> (my i386 version originally had the same problem)

Yes, you are true.
In the fault handler, we should use find_lock_page() instead of
find_get_page() to find a hugepage associated with the fault address.
After that pte_none(*pte) should be called again to check whether 
some races has happened.

> > +/*      update_mmu_cache(vma, address, *pte); */
> 
> I have not studied low level IA64 VM in detail, but don't you need
> some kind of TLB flush here?
> 
> -Andi


Thank you,
Hirokazu Takahashi.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/