From: Andrew Morton <akpm@linux-foundation.org>
To: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Cc: William Irwin <wli@holomorphy.com>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/5] hugetlb: try to search again if it is really needed
Date: Wed, 1 Feb 2012 14:43:53 -0800 [thread overview]
Message-ID: <20120201144353.7c75b5b6.akpm@linux-foundation.org> (raw)
In-Reply-To: <4F101969.8050601@linux.vnet.ibm.com>
On Fri, 13 Jan 2012 19:45:45 +0800
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> wrote:
> Search again only if some holes may be skipped in the first time
>
> Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
> ---
> arch/x86/mm/hugetlbpage.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
> index e12debc..6bf5735 100644
> --- a/arch/x86/mm/hugetlbpage.c
> +++ b/arch/x86/mm/hugetlbpage.c
> @@ -309,9 +309,8 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
> struct hstate *h = hstate_file(file);
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
> - unsigned long base = mm->mmap_base, addr = addr0;
> + unsigned long base = mm->mmap_base, addr = addr0, start_addr;
grr. The multiple-definitions-per-line thing is ugly, makes for more
patch conflicts and reduces opportunities to add useful comments.
--- a/arch/x86/mm/hugetlbpage.c~hugetlb-try-to-search-again-if-it-is-really-needed-fix
+++ a/arch/x86/mm/hugetlbpage.c
@@ -309,7 +309,9 @@ static unsigned long hugetlb_get_unmappe
struct hstate *h = hstate_file(file);
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
- unsigned long base = mm->mmap_base, addr = addr0, start_addr;
+ unsigned long base = mm->mmap_base;
+ unsigned long addr = addr0;
+ unsigned long start_addr;
unsigned long largest_hole = mm->cached_hole_size;
/* don't allow allocations above current base */
_
> unsigned long largest_hole = mm->cached_hole_size;
> - int first_time = 1;
>
> /* don't allow allocations above current base */
> if (mm->free_area_cache > base)
> @@ -322,6 +321,8 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
> mm->free_area_cache = base;
> }
> try_again:
> + start_addr = mm->free_area_cache;
> +
> /* make sure it can fit in the remaining address space */
> if (mm->free_area_cache < len)
> goto fail;
> @@ -357,10 +358,9 @@ fail:
> * if hint left us with no space for the requested
> * mapping then try again:
> */
> - if (first_time) {
> + if (start_addr != base) {
> mm->free_area_cache = base;
> largest_hole = 0;
> - first_time = 0;
> goto try_again;
The code used to retry a single time. With this change the retrying is
potentially infinite. What is the reason for this change? What is the
potential for causing a lockup?
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@linux-foundation.org>
To: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Cc: William Irwin <wli@holomorphy.com>,
linux-mm@kvack.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/5] hugetlb: try to search again if it is really needed
Date: Wed, 1 Feb 2012 14:43:53 -0800 [thread overview]
Message-ID: <20120201144353.7c75b5b6.akpm@linux-foundation.org> (raw)
In-Reply-To: <4F101969.8050601@linux.vnet.ibm.com>
On Fri, 13 Jan 2012 19:45:45 +0800
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> wrote:
> Search again only if some holes may be skipped in the first time
>
> Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
> ---
> arch/x86/mm/hugetlbpage.c | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
> index e12debc..6bf5735 100644
> --- a/arch/x86/mm/hugetlbpage.c
> +++ b/arch/x86/mm/hugetlbpage.c
> @@ -309,9 +309,8 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
> struct hstate *h = hstate_file(file);
> struct mm_struct *mm = current->mm;
> struct vm_area_struct *vma;
> - unsigned long base = mm->mmap_base, addr = addr0;
> + unsigned long base = mm->mmap_base, addr = addr0, start_addr;
grr. The multiple-definitions-per-line thing is ugly, makes for more
patch conflicts and reduces opportunities to add useful comments.
--- a/arch/x86/mm/hugetlbpage.c~hugetlb-try-to-search-again-if-it-is-really-needed-fix
+++ a/arch/x86/mm/hugetlbpage.c
@@ -309,7 +309,9 @@ static unsigned long hugetlb_get_unmappe
struct hstate *h = hstate_file(file);
struct mm_struct *mm = current->mm;
struct vm_area_struct *vma;
- unsigned long base = mm->mmap_base, addr = addr0, start_addr;
+ unsigned long base = mm->mmap_base;
+ unsigned long addr = addr0;
+ unsigned long start_addr;
unsigned long largest_hole = mm->cached_hole_size;
/* don't allow allocations above current base */
_
> unsigned long largest_hole = mm->cached_hole_size;
> - int first_time = 1;
>
> /* don't allow allocations above current base */
> if (mm->free_area_cache > base)
> @@ -322,6 +321,8 @@ static unsigned long hugetlb_get_unmapped_area_topdown(struct file *file,
> mm->free_area_cache = base;
> }
> try_again:
> + start_addr = mm->free_area_cache;
> +
> /* make sure it can fit in the remaining address space */
> if (mm->free_area_cache < len)
> goto fail;
> @@ -357,10 +358,9 @@ fail:
> * if hint left us with no space for the requested
> * mapping then try again:
> */
> - if (first_time) {
> + if (start_addr != base) {
> mm->free_area_cache = base;
> largest_hole = 0;
> - first_time = 0;
> goto try_again;
The code used to retry a single time. With this change the retrying is
potentially infinite. What is the reason for this change? What is the
potential for causing a lockup?
next prev parent reply other threads:[~2012-02-01 22:43 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-13 11:44 [PATCH 1/5] hugetlbfs: fix hugetlb_get_unmapped_area Xiao Guangrong
2012-01-13 11:44 ` Xiao Guangrong
2012-01-13 11:44 ` [PATCH 2/5] hugetlb: drop prev_vma in hugetlb_get_unmapped_area_topdown Xiao Guangrong
2012-01-13 11:44 ` Xiao Guangrong
2012-03-07 22:01 ` Andrew Morton
2012-03-07 22:01 ` Andrew Morton
2012-03-08 2:28 ` Xiao Guangrong
2012-03-08 2:28 ` Xiao Guangrong
2012-01-13 11:45 ` [PATCH 3/5] hugetlb: try to search again if it is really needed Xiao Guangrong
2012-01-13 11:45 ` Xiao Guangrong
2012-02-01 22:43 ` Andrew Morton [this message]
2012-02-01 22:43 ` Andrew Morton
2012-02-02 5:19 ` Xiao Guangrong
2012-02-02 5:19 ` Xiao Guangrong
2012-01-13 11:46 ` [PATCH 4/5] mm: do not reset cached_hole_size when vma is unmapped Xiao Guangrong
2012-01-13 11:46 ` Xiao Guangrong
2012-01-13 11:47 ` [PATCH 5/5] mm: search from free_area_cache for the bigger size Xiao Guangrong
2012-01-13 11:47 ` Xiao Guangrong
2012-02-01 22:44 ` Andrew Morton
2012-02-01 22:44 ` Andrew Morton
2012-02-02 7:07 ` Xiao Guangrong
2012-02-02 7:07 ` Xiao Guangrong
2012-01-31 6:05 ` [PATCH 1/5] hugetlbfs: fix hugetlb_get_unmapped_area Xiao Guangrong
2012-01-31 6:05 ` Xiao Guangrong
2012-02-01 22:43 ` Andrew Morton
2012-02-01 22:43 ` Andrew Morton
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=20120201144353.7c75b5b6.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=wli@holomorphy.com \
--cc=xiaoguangrong@linux.vnet.ibm.com \
/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.