From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from zps35.corp.google.com (zps35.corp.google.com [172.25.146.35]) by smtp-out.google.com with ESMTP id l9A7oEKT018478 for ; Wed, 10 Oct 2007 00:50:14 -0700 Received: from rv-out-0910.google.com (rvbg11.prod.google.com [10.140.83.11]) by zps35.corp.google.com with ESMTP id l9A7oD4j012507 for ; Wed, 10 Oct 2007 00:50:14 -0700 Received: by rv-out-0910.google.com with SMTP id g11so99750rvb for ; Wed, 10 Oct 2007 00:50:13 -0700 (PDT) Message-ID: Date: Wed, 10 Oct 2007 00:50:13 -0700 From: "Ken Chen" Subject: Re: [rfc] more granular page table lock for hugepages In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071008225234.GC27824@linux-os.sc.intel.com> <1191963958.12131.43.camel@dyn9047017100.beaverton.ibm.com> <20071010001523.GA30676@linux-os.sc.intel.com> Sender: owner-linux-mm@kvack.org Return-Path: To: "Siddha, Suresh B" Cc: Badari Pulavarty , linux-mm List-ID: On 10/9/07, Ken Chen wrote: > That's what I figures. In that case, why don't we get rid of all spin > lock in the fast path of follow_hugetlb_pages. > > follow_hugetlb_page is called from get_user_pages, which should > already hold mm->mmap_sem in read mode. That means page table tear > down can not happen. We do a racy read on page table chain. If a > race happened with another thread, no big deal, it will just fall into > hugetlb_fault() which will then serialize with > hugetlb_instantiation_mutex or mm->page_table_lock. And that's slow > path anyway. never mind. ftruncate can come through in another path removes mapping without holding mm->mmap_sem. So much for the crazy idea. -- 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/ . Don't email: email@kvack.org