All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adam Litke <agl@us.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	ak@suse.de, hugh@veritas.com
Subject: Re: [PATCH 2/3] hugetlb: Demand fault handler
Date: Thu, 13 Oct 2005 10:49:28 -0500	[thread overview]
Message-ID: <1129218568.8797.7.camel@localhost.localdomain> (raw)
In-Reply-To: <20051012060934.GA14943@localhost.localdomain>

Thanks for the review and comments...

On Wed, 2005-10-12 at 16:09 +1000, David Gibson wrote:
> On Tue, Oct 11, 2005 at 01:32:38PM -0500, Adam Litke wrote:
> > Version 5 (Tue, 11 Oct 2005)
> > 	Deal with hugetlbfs file truncation in find_get_huge_page()
> > Version 4 (Mon, 03 Oct 2005)
> > 	Make find_get_huge_page bale properly when add_to_page_cache fails
> > 	  due to OOM conditions
> > Version 3 (Thu, 08 Sep 2005)
> >         Organized logic in hugetlb_pte_fault() by breaking out
> >           find_get_page/alloc_huge_page logic into separate function
> >         Removed a few more paranoid checks  ( Thanks       )
> >         Fixed tlb flushing in a race case   ( Yanmin Zhang )
> > 
> > Version 2 (Wed, 17 Aug 2005)
> >         Removed spurious WARN_ON()
> >     Patches added earlier in the series (now in mainline):
> >         Check for p?d_none() in arch/i386/mm/hugetlbpage.c:huge_pte_offset()
> >         Move i386 stale pte check into huge_pte_alloc()
> 
> I'm not sure this does fully deal with truncation, I'm afraid - it
> will deal with a truncation well before the fault, but not a
> concurrent truncate().  We'll need the truncate_count/retry logic from
> do_no_page, I think.  Andi/Hugh, can you confirm that's correct?

Ok.  I can see why we need that.

> > Initial Post (Fri, 05 Aug 2005)
> > 
> > Below is a patch to implement demand faulting for huge pages.  The main
> > motivation for changing from prefaulting to demand faulting is so that
> > huge page memory areas can be allocated according to NUMA policy.
> > 
> > Thanks to consolidated hugetlb code, switching the behavior requires changing
> > only one fault handler.  The bulk of the patch just moves the logic from 
> > hugelb_prefault() to hugetlb_pte_fault() and find_get_huge_page().
> 
> While we're at it - it's a minor nit, but I find the distinction
> between hugetlb_pte_fault() and hugetlb_fault() confusing.  A better
> name for the former would be hugetlb_no_page(), in which case we
> should probably also move the border between it and
> hugetlb_find_get_page() to match the boundary between do_no_page() and
> mapping->nopage.
> 
> How about this, for example:

Yeah, I suppose that division makes more sense when comparing to the
normal fault handler code.

> @@ -338,57 +337,128 @@
>  	spin_unlock(&mm->page_table_lock);
>  }
>  
> -int hugetlb_prefault(struct address_space *mapping, struct vm_area_struct *vma)
> +static struct page *hugetlbfs_nopage(struct vm_area_struct *vma,

<snip>

> +	/* Check to make sure the mapping hasn't been truncated */
> +	size = i_size_read(inode) >> HPAGE_SHIFT;
> +	if (pgoff >= size)
> +		return NULL;
> +
> + retry:
> +	page = find_get_page(mapping, pgoff);
> +	if (page)
> +		/* Another thread won the race */
> +		return page;

Both of those returns could be changed to goto out so that the function
has only one exit path.  Isn't that what we want?

-- 
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center


WARNING: multiple messages have this Message-ID (diff)
From: Adam Litke <agl@us.ibm.com>
To: David Gibson <david@gibson.dropbear.id.au>
Cc: akpm@osdl.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	ak@suse.de, hugh@veritas.com
Subject: Re: [PATCH 2/3] hugetlb: Demand fault handler
Date: Thu, 13 Oct 2005 10:49:28 -0500	[thread overview]
Message-ID: <1129218568.8797.7.camel@localhost.localdomain> (raw)
In-Reply-To: <20051012060934.GA14943@localhost.localdomain>

Thanks for the review and comments...

On Wed, 2005-10-12 at 16:09 +1000, David Gibson wrote:
> On Tue, Oct 11, 2005 at 01:32:38PM -0500, Adam Litke wrote:
> > Version 5 (Tue, 11 Oct 2005)
> > 	Deal with hugetlbfs file truncation in find_get_huge_page()
> > Version 4 (Mon, 03 Oct 2005)
> > 	Make find_get_huge_page bale properly when add_to_page_cache fails
> > 	  due to OOM conditions
> > Version 3 (Thu, 08 Sep 2005)
> >         Organized logic in hugetlb_pte_fault() by breaking out
> >           find_get_page/alloc_huge_page logic into separate function
> >         Removed a few more paranoid checks  ( Thanks       )
> >         Fixed tlb flushing in a race case   ( Yanmin Zhang )
> > 
> > Version 2 (Wed, 17 Aug 2005)
> >         Removed spurious WARN_ON()
> >     Patches added earlier in the series (now in mainline):
> >         Check for p?d_none() in arch/i386/mm/hugetlbpage.c:huge_pte_offset()
> >         Move i386 stale pte check into huge_pte_alloc()
> 
> I'm not sure this does fully deal with truncation, I'm afraid - it
> will deal with a truncation well before the fault, but not a
> concurrent truncate().  We'll need the truncate_count/retry logic from
> do_no_page, I think.  Andi/Hugh, can you confirm that's correct?

Ok.  I can see why we need that.

> > Initial Post (Fri, 05 Aug 2005)
> > 
> > Below is a patch to implement demand faulting for huge pages.  The main
> > motivation for changing from prefaulting to demand faulting is so that
> > huge page memory areas can be allocated according to NUMA policy.
> > 
> > Thanks to consolidated hugetlb code, switching the behavior requires changing
> > only one fault handler.  The bulk of the patch just moves the logic from 
> > hugelb_prefault() to hugetlb_pte_fault() and find_get_huge_page().
> 
> While we're at it - it's a minor nit, but I find the distinction
> between hugetlb_pte_fault() and hugetlb_fault() confusing.  A better
> name for the former would be hugetlb_no_page(), in which case we
> should probably also move the border between it and
> hugetlb_find_get_page() to match the boundary between do_no_page() and
> mapping->nopage.
> 
> How about this, for example:

Yeah, I suppose that division makes more sense when comparing to the
normal fault handler code.

> @@ -338,57 +337,128 @@
>  	spin_unlock(&mm->page_table_lock);
>  }
>  
> -int hugetlb_prefault(struct address_space *mapping, struct vm_area_struct *vma)
> +static struct page *hugetlbfs_nopage(struct vm_area_struct *vma,

<snip>

> +	/* Check to make sure the mapping hasn't been truncated */
> +	size = i_size_read(inode) >> HPAGE_SHIFT;
> +	if (pgoff >= size)
> +		return NULL;
> +
> + retry:
> +	page = find_get_page(mapping, pgoff);
> +	if (page)
> +		/* Another thread won the race */
> +		return page;

Both of those returns could be changed to goto out so that the function
has only one exit path.  Isn't that what we want?

-- 
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2005-10-13 15:49 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-11 18:24 [PATCH 0/3] Demand faulting for hugetlb Adam Litke
2005-10-11 18:24 ` Adam Litke
2005-10-11 18:31 ` [PATCH 1/3] hugetlb: Remove get_user_pages optimization Adam Litke
2005-10-11 18:31   ` Adam Litke
2005-10-11 18:32 ` [PATCH 0/3] Demand faulting for hugetlb Andrew Morton
2005-10-11 18:32   ` Andrew Morton
2005-10-11 19:16   ` [PATCH 3/3] hugetlb: Simple overcommit check Adam Litke
2005-10-11 19:16     ` Adam Litke
2005-10-11 18:32 ` [PATCH 2/3] hugetlb: Demand fault handler Adam Litke
2005-10-11 18:32   ` Adam Litke
2005-10-12  6:09   ` David Gibson
2005-10-12  6:09     ` David Gibson
2005-10-12  7:25     ` Hugh Dickins
2005-10-12  7:25       ` Hugh Dickins
2005-10-13 15:49     ` Adam Litke [this message]
2005-10-13 15:49       ` Adam Litke
2005-10-14  1:24       ` David Gibson
2005-10-14  1:24         ` David Gibson
2005-10-11 18:33 ` [PATCH 3/3] hugetlb: Simple overcommit check Adam Litke
2005-10-11 18:33   ` Adam Litke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1129218568.8797.7.camel@localhost.localdomain \
    --to=agl@us.ibm.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=david@gibson.dropbear.id.au \
    --cc=hugh@veritas.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.