[merged] mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch removed from -mm tree

[merged] mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch removed from -mm tree

[akpm]

Subject: [merged] mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch removed from -mm tree
To: m.mizuma@jp.fujitsu.com,aneesh.kumar@linux.vnet.ibm.com,iamjoonsoo.kim@lge.com,kosaki.motohiro@jp.fujitsu.com,liwanp@linux.vnet.ibm.com,mhocko@suse.cz,n-horiguchi@ah.jp.nec.com,stable@vger.kernel.org,mm-commits@vger.kernel.org
From: akpm@linux-foundation.org
Date: Tue, 08 Apr 2014 13:58:05 -0700


The patch titled
     Subject: mm: hugetlb: fix softlockup when a large number of hugepages are freed.
has been removed from the -mm tree.  Its filename was
     mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch

This patch was dropped because it was merged into mainline or a subsystem tree

------------------------------------------------------
From: "Mizuma, Masayoshi" <m.mizuma@jp.fujitsu.com>
Subject: mm: hugetlb: fix softlockup when a large number of hugepages are freed.

When I decrease the value of nr_hugepage in procfs a lot, softlockup
happens.  It is because there is no chance of context switch during this
process.

On the other hand, when I allocate a large number of hugepages, there is
some chance of context switch.  Hence softlockup doesn't happen during
this process.  So it's necessary to add the context switch in the freeing
process as same as allocating process to avoid softlockup.

When I freed 12 TB hugapages with kernel-2.6.32-358.el6, the freeing
process occupied a CPU over 150 seconds and following softlockup message
appeared twice or more.


$ echo 6000000 > /proc/sys/vm/nr_hugepages
$ cat /proc/sys/vm/nr_hugepages
6000000
$ grep ^Huge /proc/meminfo
HugePages_Total:   6000000
HugePages_Free:    6000000
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
$ echo 0 > /proc/sys/vm/nr_hugepages

BUG: soft lockup - CPU#16 stuck for 67s! [sh:12883] ...
Pid: 12883, comm: sh Not tainted 2.6.32-358.el6.x86_64 #1
Call Trace:
 [<ffffffff8115a438>] ? free_pool_huge_page+0xb8/0xd0
 [<ffffffff8115a578>] ? set_max_huge_pages+0x128/0x190
 [<ffffffff8115c663>] ? hugetlb_sysctl_handler_common+0x113/0x140
 [<ffffffff8115c6de>] ? hugetlb_sysctl_handler+0x1e/0x20
 [<ffffffff811f3097>] ? proc_sys_call_handler+0x97/0xd0
 [<ffffffff811f30e4>] ? proc_sys_write+0x14/0x20
 [<ffffffff81180f98>] ? vfs_write+0xb8/0x1a0
 [<ffffffff81181891>] ? sys_write+0x51/0x90
 [<ffffffff810dc565>] ? __audit_syscall_exit+0x265/0x290
 [<ffffffff8100b072>] ? system_call_fastpath+0x16/0x1b

I have not confirmed this problem with upstream kernels because I am not
able to prepare the machine equipped with 12TB memory now.  However I
confirmed that the amount of decreasing hugepages was directly
proportional to the amount of required time.

I measured required times on a smaller machine.  It showed 130-145
hugepages decreased in a millisecond.

Amount of decreasing     Required time      Decreasing rate
hugepages                     (msec)         (pages/msec)
------------------------------------------------------------
10,000 pages == 20GB         70 -  74          135-142
30,000 pages == 60GB        208 - 229          131-144

It means decrement of 6TB hugepages will trigger softlockup with the
default threshold 20sec, in this decreasing rate.

Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Wanpeng Li <liwanp@linux.vnet.ibm.com>
Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---

 mm/hugetlb.c |    1 +
 1 file changed, 1 insertion(+)

diff -puN mm/hugetlb.c~mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed mm/hugetlb.c
--- a/mm/hugetlb.c~mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed
+++ a/mm/hugetlb.c
@@ -1536,6 +1536,7 @@ static unsigned long set_max_huge_pages(
 	while (min_count < persistent_huge_pages(h)) {
 		if (!free_pool_huge_page(h, nodes_allowed, 0))
 			break;
+		cond_resched_lock(&hugetlb_lock);
 	}
 	while (count < persistent_huge_pages(h)) {
 		if (!adjust_pool_surplus(h, nodes_allowed, 1))
_

Patches currently in -mm which might be from m.mizuma@jp.fujitsu.com are

origin.patch

[PATCH] mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()

[Naoya Horiguchi]

On Tue, Apr 08, 2014 at 02:21:22PM -0700, Motohiro Kosaki wrote:
> Naoya
> 
> > -----Original Message-----
> > From: Naoya Horiguchi [mailto:n-horiguchi@ah.jp.nec.com]
> > Sent: Tuesday, April 08, 2014 5:20 PM
> > To: akpm@linux-foundation.org
> > Cc: mhocko@suse.cz; Motohiro Kosaki JP; iamjoonsoo.kim@lge.com; aneesh.kumar@linux.vnet.ibm.com; m.mizuma@jp.fujitsu.com
> > Subject: Re: [merged] mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch removed from -mm tree
> > 
> > Hi Andrew,
> > # off list
> > 
> > This patch is obsolete and latest version is ver.2.
> > http://www.spinics.net/lists/linux-mm/msg71283.html
> > Could you queue the new one to go to mainline?
> 
> [merged] mean the patch has already been merged the linus tree. So, it can be changed. Please make
> an incremental patch.

Here it is.

Thanks,
Naoya Horiguchi
---
Subject: [PATCH] mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()

From: "Mizuma, Masayoshi" <m.mizuma@jp.fujitsu.com>

soft lockup in freeing gigantic hugepage fixed in commit 55f67141a892
"mm: hugetlb: fix softlockup when a large number of hugepages are freed."
can happen in return_unused_surplus_pages(), so let's fix it.

Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Michal Hocko <mhocko@suse.cz>
Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: <stable@vger.kernel.org>
---
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 7d57af2..761ef5b 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1160,6 +1160,7 @@ static void return_unused_surplus_pages(struct hstate *h,
 	while (nr_pages--) {
 		if (!free_pool_huge_page(h, &node_states[N_MEMORY], 1))
 			break;
+		cond_resched_lock(&hugetlb_lock);
 	}
 }
 

--
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>

Re: [PATCH] mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()

[Masayoshi Mizuma]

Hi Naoya,

On Tue, 8 Apr 2014 17:46:25 -0400 Naoya Horiguchi wrote:
> On Tue, Apr 08, 2014 at 02:21:22PM -0700, Motohiro Kosaki wrote:
>> Naoya
>>
>>> -----Original Message-----
>>> From: Naoya Horiguchi [mailto:n-horiguchi@ah.jp.nec.com]
>>> Sent: Tuesday, April 08, 2014 5:20 PM
>>> To: akpm@linux-foundation.org
>>> Cc: mhocko@suse.cz; Motohiro Kosaki JP; iamjoonsoo.kim@lge.com; aneesh.kumar@linux.vnet.ibm.com; m.mizuma@jp.fujitsu.com
>>> Subject: Re: [merged] mm-hugetlb-fix-softlockup-when-a-large-number-of-hugepages-are-freed.patch removed from -mm tree
>>>
>>> Hi Andrew,
>>> # off list
>>>
>>> This patch is obsolete and latest version is ver.2.
>>> http://www.spinics.net/lists/linux-mm/msg71283.html
>>> Could you queue the new one to go to mainline?
>>
>> [merged] mean the patch has already been merged the linus tree. So, it can be changed. Please make
>> an incremental patch.
> 
> Here it is.

Thank you for posting this incremental patch! 

Thanks,
Masayoshi Mizuma

> 
> Thanks,
> Naoya Horiguchi
> ---
> Subject: [PATCH] mm/hugetlb.c: add cond_resched_lock() in return_unused_surplus_pages()
> 
> From: "Mizuma, Masayoshi" <m.mizuma@jp.fujitsu.com>
> 
> soft lockup in freeing gigantic hugepage fixed in commit 55f67141a892
> "mm: hugetlb: fix softlockup when a large number of hugepages are freed."
> can happen in return_unused_surplus_pages(), so let's fix it.
> 
> Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
> Signed-off-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
> Cc: Michal Hocko <mhocko@suse.cz>
> Cc: Aneesh Kumar <aneesh.kumar@linux.vnet.ibm.com>
> Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
> Cc: <stable@vger.kernel.org>
> ---
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 7d57af2..761ef5b 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1160,6 +1160,7 @@ static void return_unused_surplus_pages(struct hstate *h,
>   	while (nr_pages--) {
>   		if (!free_pool_huge_page(h, &node_states[N_MEMORY], 1))
>   			break;
> +		cond_resched_lock(&hugetlb_lock);
>   	}
>   }
>   
> 

--
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>