From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1163186AbcG1Gn6 (ORCPT <rfc822;w@1wt.eu>);
	Thu, 28 Jul 2016 02:43:58 -0400
Received: from TYO200.gate.nec.co.jp ([210.143.35.50]:34745 "EHLO
	tyo200.gate.nec.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1163075AbcG1Gnt convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Thu, 28 Jul 2016 02:43:49 -0400
From: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
To: Jia He <hejianet@gmail.com>
CC: "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Mike Kravetz <mike.kravetz@oracle.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Michal Hocko <mhocko@suse.com>,
        "Dave Hansen" <dave.hansen@linux.intel.com>,
        Paul Gortmaker <paul.gortmaker@windriver.com>
Subject: Re: [PATCH V2] mm/hugetlb: Avoid soft lockup in set_max_huge_pages()
Thread-Topic: [PATCH V2] mm/hugetlb: Avoid soft lockup in
 set_max_huge_pages()
Thread-Index: AQHR6HtWKhsch9qcHEmWppS10zc9oqAszkwA
Date: Thu, 28 Jul 2016 06:41:28 +0000
Message-ID: <20160728064128.GA11208@hori1.linux.bs1.fc.nec.co.jp>
References: <1469674442-14848-1-git-send-email-hejianet@gmail.com>
In-Reply-To: <1469674442-14848-1-git-send-email-hejianet@gmail.com>
Accept-Language: en-US, ja-JP
Content-Language: ja-JP
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.128.101.5]
Content-Type: text/plain; charset="iso-2022-jp"
Content-ID: <9696EB4DFFE25245A048AC55D9B00807@gisp.nec.co.jp>
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Jul 28, 2016 at 10:54:02AM +0800, Jia He wrote:
> In powerpc servers with large memory(32TB), we watched several soft
> lockups for hugepage under stress tests.
> The call trace are as follows:
> 1.
> get_page_from_freelist+0x2d8/0xd50  
> __alloc_pages_nodemask+0x180/0xc20  
> alloc_fresh_huge_page+0xb0/0x190    
> set_max_huge_pages+0x164/0x3b0      
> 
> 2.
> prep_new_huge_page+0x5c/0x100             
> alloc_fresh_huge_page+0xc8/0x190          
> set_max_huge_pages+0x164/0x3b0
> 
> This patch is to fix such soft lockups. It is safe to call cond_resched() 
> there because it is out of spin_lock/unlock section.
> 
> Signed-off-by: Jia He <hejianet@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
> Cc: Mike Kravetz <mike.kravetz@oracle.com>
> Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Paul Gortmaker <paul.gortmaker@windriver.com>

Looks good to me.

Reviewed-by: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>

Thanks,
Naoya Horiguchi

> 
> ---
> Changes in V2: move cond_resched to a common calling site in set_max_huge_pages
> 
>  mm/hugetlb.c | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index abc1c5f..9284280 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -2216,6 +2216,10 @@ static unsigned long set_max_huge_pages(struct hstate *h, unsigned long count,
>  		 * and reducing the surplus.
>  		 */
>  		spin_unlock(&hugetlb_lock);
> +
> +		/* yield cpu to avoid soft lockup */
> +		cond_resched();
> +
>  		if (hstate_is_gigantic(h))
>  			ret = alloc_fresh_gigantic_page(h, nodes_allowed);
>  		else
> -- 
> 2.5.0
>