All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Andy Whitcroft <apw@canonical.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Hugh Dickins <hugh@veritas.com>,
	Lee Schermerhorn <Lee.Schermerhorn@hp.com>,
	Greg KH <gregkh@suse.de>,
	Maksim Yevmenkin <maksim.yevmenkin@gmail.com>,
	Nick Piggin <npiggin@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	will@crowder-design.com, Rik van Riel <riel@redhat.com>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
	Mikos Szeredi <miklos@szeredi.hu>,
	wli@movementarian.org
Subject: Re: [PATCH] Do not account for the address space used by hugetlbfs using VM_ACCOUNT V2 (Was Linus 2.6.29-rc4)
Date: Wed, 11 Feb 2009 16:34:16 +0000	[thread overview]
Message-ID: <20090211163416.GA2733@csn.ul.ie> (raw)
In-Reply-To: <20090211160340.GH25898@shadowen.org>

On Wed, Feb 11, 2009 at 04:03:40PM +0000, Andy Whitcroft wrote:
> On Wed, Feb 11, 2009 at 02:20:04PM +0000, Mel Gorman wrote:
> > On Wed, Feb 11, 2009 at 12:03:17PM +0000, Andy Whitcroft wrote:
> > > > <SNIP>
> > > >
> > > > Yes, and this was a mistake. For noreserve mappings, we may now be taking
> > > > twice the amount of quota and probably leaking it. This is wrong and I need
> > > > to move the check for quota below the check for VM_NORESERVE. Good spot.
> > > 
> > > Thanks.
> > > 
> > 
> > How about this?
> > 
> > =====
> > [PATCH] Do not account for hugetlbfs quota at mmap() time if mapping *_NORESERVE
> > 
> > Commit 5a6fe125950676015f5108fb71b2a67441755003 brought hugetlbfs more in line
> > with the core VM by obeying VM_NORESERVE and not reserving hugepages for both
> > shared and private mappings when [SHM|MAP]_NORESERVE are specified. However,
> > it is still taking filesystem quota unconditionally and this leads to
> > double-accounting.
> > 
> > At fault time, if there are no reserves and attempt is made to allocate the
> > page and account for filesystem quota. If either fail, the fault fails. This
> > patch prevents quota being taken when [SHM|MAP]_NORESERVE is specified.
> > To help prevent this mistake happening again, it improves the documentation
> > of hugetlb_reserve_pages().
> > 
> > Reported-by: Andy Whitcroft <apw@canonical.com>
> > Signed-off-by: Mel Gorman <mel@csn.ul.ie>
> > --- 
> >  hugetlb.c |   29 +++++++++++++++++++++++------
> >  1 file changed, 23 insertions(+), 6 deletions(-)
> > 
> > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > index 2074642..b0b63cd 100644
> > --- a/mm/hugetlb.c
> > +++ b/mm/hugetlb.c
> > @@ -2289,24 +2289,41 @@ int hugetlb_reserve_pages(struct inode *inode,
> >  	if (chg < 0)
> >  		return chg;
> >  
> > -	if (hugetlb_get_quota(inode->i_mapping, chg))
> > -		return -ENOSPC;
> > -
> >  	/*
> > -	 * Only apply hugepage reservation if asked. We still have to
> > -	 * take the filesystem quota because it is an upper limit
> > -	 * defined for the mount and not necessarily memory as a whole
> > +	 * Only apply hugepage reservation if asked. At fault time, an
> > +	 * attempt will be made for VM_NORESERVE to allocate a page
> > +	 * and filesystem quota without using reserves
> >  	 */
> >  	if (acctflag & VM_NORESERVE) {
> >  		reset_vma_resv_huge_pages(vma);
> >  		return 0;
> >  	}
> >  
> > +	/* There must be enough filesystem quota for the mapping */
> > +	if (hugetlb_get_quota(inode->i_mapping, chg))
> > +		return -ENOSPC;
> > +
> > +	/*
> > +	 * Check enough hugepages are available for the reservation.
> > +	 * Hand back the quota if there are not
> > +	 */
> >  	ret = hugetlb_acct_memory(h, chg);
> >  	if (ret < 0) {
> >  		hugetlb_put_quota(inode->i_mapping, chg);
> >  		return ret;
> >  	}
> > +
> > +	/*
> > +	 * Account for the reservations made. Shared mappings record regions
> > +	 * that have reservations as they are shared by multiple VMAs.
> > +	 * When the last VMA disappears, the region map says how much
> > +	 * the reservation was and the page cache tells how much of
> 
> how much of the area had a reservation and the page cache ...
> 
> > +	 * the reservation was consumed. Private mappings are per-VMA and
> > +	 * only the consumed reservations are tracked. When the VMA
> > +	 * disappears, the original reservation is the VMA size and the
> > +	 * consumed reservations are stored in the map. Here, we just need
> > +	 * to allocate the region map.
> > +	 */
> >  	if (!vma || vma->vm_flags & VM_SHARED)
> >  		region_add(&inode->i_mapping->private_list, from, to);
> >  	else {
> 
> I am worried about the failure semantics here.  For shared mappings we
> alloc any memory we need with region_chg(), then take quota, then apply
> it and done.  For private mappings we take the quota and then allocate
> any memory we need.  If that fails we do not return the quota?  Sounds
> like a quota leak to me?
> 

It is a quota leak.

> I think we do need to allocate the private map up when we do the
> region_chg() for the shared case.  And I think neither of those is needed
> for NORESERVE mappings?
> 

Right. This shuffle was based on the assumption quota mattered and had to
be accounted for. As you have pointed out, this was wrong and so all the
shuffling was pointless. The correct thing to do is a partial revert of
the hunk that alters hugetlb_reserve_pages() and then add back acctflag to
check VM_NORESERVE so that SHM_NORESERVE still has meaning.

After the following patch is applied, the net change to hugetlb_reserve_pages()
is small - mainly additional comments documenting what's going on.

======
Subject: [PATCH] Do not account for hugetlbfs quota at mmap() time if mapping [SHM|MAP]_NORESERVE

Commit 5a6fe125950676015f5108fb71b2a67441755003 brought hugetlbfs more in line
with the core VM by obeying VM_NORESERVE and not reserving hugepages for both
shared and private mappings when [SHM|MAP]_NORESERVE are specified. However,
it is still taking filesystem quota unconditionally.

At fault time, if there are no reserves and attempt is made to allocate
the page and account for filesystem quota. If either fail, the fault
fails. The impact is that quota is getting accounted for twice. This patch
partially reverts 5a6fe125950676015f5108fb71b2a67441755003.  To help
prevent this mistake happening again, it improves the documentation of
hugetlb_reserve_pages()

Reported-by: Andy Whitcroft <apw@canonical.com>
Signed-off-by: Mel Gorman <mel@csn.ul.ie>

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2074642..107da3d 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2272,10 +2272,18 @@ int hugetlb_reserve_pages(struct inode *inode,
 					struct vm_area_struct *vma,
 					int acctflag)
 {
-	long ret = 0, chg;
+	long ret, chg;
 	struct hstate *h = hstate_inode(inode);
 
 	/*
+	 * Only apply hugepage reservation if asked. At fault time, an
+	 * attempt will be made for VM_NORESERVE to allocate a page
+	 * and filesystem quota without using reserves
+	 */
+	if (acctflag & VM_NORESERVE)
+		return 0;
+
+	/*
 	 * Shared mappings base their reservation on the number of pages that
 	 * are already allocated on behalf of the file. Private mappings need
 	 * to reserve the full area even if read-only as mprotect() may be
@@ -2283,42 +2291,47 @@ int hugetlb_reserve_pages(struct inode *inode,
 	 */
 	if (!vma || vma->vm_flags & VM_SHARED)
 		chg = region_chg(&inode->i_mapping->private_list, from, to);
-	else
+	else {
+		struct resv_map *resv_map = resv_map_alloc();
+		if (!resv_map)
+			return -ENOMEM;
+
 		chg = to - from;
 
+		set_vma_resv_map(vma, resv_map);
+		set_vma_resv_flags(vma, HPAGE_RESV_OWNER);
+	}
+
 	if (chg < 0)
 		return chg;
 
+	/* There must be enough filesystem quota for the mapping */
 	if (hugetlb_get_quota(inode->i_mapping, chg))
 		return -ENOSPC;
 
 	/*
-	 * Only apply hugepage reservation if asked. We still have to
-	 * take the filesystem quota because it is an upper limit
-	 * defined for the mount and not necessarily memory as a whole
+	 * Check enough hugepages are available for the reservation.
+	 * Hand back the quota if there are not
 	 */
-	if (acctflag & VM_NORESERVE) {
-		reset_vma_resv_huge_pages(vma);
-		return 0;
-	}
-
 	ret = hugetlb_acct_memory(h, chg);
 	if (ret < 0) {
 		hugetlb_put_quota(inode->i_mapping, chg);
 		return ret;
 	}
+
+	/*
+	 * Account for the reservations made. Shared mappings record regions
+	 * that have reservations as they are shared by multiple VMAs.
+	 * When the last VMA disappears, the region map says how much
+	 * the reservation was and the page cache tells how much of
+	 * the reservation was consumed. Private mappings are per-VMA and
+	 * only the consumed reservations are tracked. When the VMA
+	 * disappears, the original reservation is the VMA size and the
+	 * consumed reservations are stored in the map. Hence, nothing
+	 * else has to be done for private mappings here
+	 */
 	if (!vma || vma->vm_flags & VM_SHARED)
 		region_add(&inode->i_mapping->private_list, from, to);
-	else {
-		struct resv_map *resv_map = resv_map_alloc();
-
-		if (!resv_map)
-			return -ENOMEM;
-
-		set_vma_resv_map(vma, resv_map);
-		set_vma_resv_flags(vma, HPAGE_RESV_OWNER);
-	}
-
 	return 0;
 }
 

  reply	other threads:[~2009-02-11 16:34 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-08 21:01 Linus 2.6.29-rc4 Linus Torvalds
2009-02-09  1:21 ` Arjan van de Ven
2009-02-09  8:28   ` Ingo Molnar
2009-02-09 12:18     ` Avi Kivity
2009-02-09 13:34 ` Gerd Hoffmann
2009-02-09 15:04   ` Steven Noonan
2009-02-09 18:26 ` Oopses and ACPI problems (Linus 2.6.29-rc4) Darren Salt
2009-02-09 23:49   ` Ingo Molnar
2009-02-09 23:49     ` Ingo Molnar
2009-02-10 14:12     ` Darren Salt
2009-02-10 14:12       ` Darren Salt
2009-02-10 14:54       ` [PATCH 2.6.29-rc4] Restore ACPI reporting via /proc/acpi/events for EeePC & other Asus laptops Darren Salt
2009-02-10 14:54         ` Darren Salt
2009-02-24 11:31         ` Corentin Chary
2009-02-10 15:04       ` Oopses and ACPI problems (Linus 2.6.29-rc4) Matthew Garrett
2009-02-10 15:04         ` Matthew Garrett
2009-02-10 15:15         ` Darren Salt
2009-02-10 15:15           ` Darren Salt
2009-02-10 15:45           ` Matthew Garrett
2009-02-10 15:45             ` Matthew Garrett
2009-02-10 16:03             ` Darren Salt
2009-02-23 16:39               ` Matthew Garrett
2009-02-23 16:39                 ` Matthew Garrett
2009-02-24 15:29                 ` Darren Salt
2009-02-24 16:00                   ` Matthew Garrett
2009-02-24 16:00                     ` Matthew Garrett
2009-02-24 19:45                     ` Darren Salt
2009-02-10 16:06             ` Corentin Chary
2009-02-10 19:16               ` Darren Salt
2009-02-11  2:03                 ` Matthew Garrett
2009-02-11  2:03                   ` Matthew Garrett
2009-02-11  1:23               ` yakui_zhao
2009-04-19  1:56           ` [PATCH] eee-laptop: Register as a pci-hotplug device Matthew Garrett
2009-04-19  7:20             ` Corentin Chary
2009-04-19 15:13               ` Matthew Garrett
2009-04-25 14:12                 ` Corentin Chary
2009-04-26 17:16                   ` Matthew Garrett
2009-04-26 20:51                     ` Corentin Chary
2009-02-10  1:06   ` Oopses and ACPI problems (Linus 2.6.29-rc4) yakui_zhao
2009-02-10  1:06     ` yakui_zhao
2009-02-10 14:02 ` [PATCH] Do not account for the address space used by hugetlbfs using VM_ACCOUNT V2 (Was Linus 2.6.29-rc4) Mel Gorman
2009-02-10 23:45   ` Andrew Morton
2009-02-11 11:15     ` Mel Gorman
2009-02-11  9:43   ` Andy Whitcroft
2009-02-11 10:30     ` Mel Gorman
2009-02-11 12:03       ` Andy Whitcroft
2009-02-11 14:20         ` Mel Gorman
2009-02-11 16:03           ` Andy Whitcroft
2009-02-11 16:34             ` Mel Gorman [this message]
2009-02-11 16:43               ` Andy Whitcroft

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=20090211163416.GA2733@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=Lee.Schermerhorn@hp.com \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=gregkh@suse.de \
    --cc=hugh@veritas.com \
    --cc=kamezawa.hiroyu@jp.fujitsu.com \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maksim.yevmenkin@gmail.com \
    --cc=miklos@szeredi.hu \
    --cc=npiggin@suse.de \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.org \
    --cc=will@crowder-design.com \
    --cc=wli@movementarian.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.