Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3306776imu; Sun, 11 Nov 2018 12:03:08 -0800 (PST) X-Google-Smtp-Source: AJdET5fgjhpv3lddEPm9nDTFTV1MQ8zZCkuPPjCV4ir3u1maTklXJboSP8NiLpwUQQEl34p7twRq X-Received: by 2002:a63:5b1f:: with SMTP id p31mr14909687pgb.56.1541966588456; Sun, 11 Nov 2018 12:03:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541966588; cv=none; d=google.com; s=arc-20160816; b=GG1WzrQDR+AGVWxJVtSs4m7PNiBYUxtFqolIPEi0ZS7DgkIg4OCOABsppYTq7wUIfc SwjHSeVBoqBlxtqc+dJiiYFw2RJ+f6Sv0GA+YOCcmtC0Y7FUAnKzjqelG8SAJCg7SbmU B11Qkwk1S6ZodsN/FOAN9zNVoIc2ax4mAJadxow/C4IKF9nyeZgEp4RIP0FRA8LAs8hG 2Nl2I0ryelm42Zh002EruGgrlA/zAq904kEnVRw0iv+ldlckZOHO8zvmtN8j7bLUvrz9 yDvzCvJl1skSKWPbJU3xZ+akcGBjuC+1hxl7BHDCo2O+oPn2P1eY3KvPBoDAW0kSx++d 0qgQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=80U71AxognGcaXESzt7Md28X4VMs/9f3vWOBZJJh5lA=; b=h3mqyJ2EdDrx1ekcm2gbXEmbuTQMj3KRpEDxDAKzk10Ibj35Hn5yLJ9LIasumBSicH m6RHZYvDCWeacRVyuK5nJURk+7fyMucQwHvZBavCPAdUZX3YBcuEz3fJ84y1AHetbMoi rhl5T3R79c0mn2w0VyqpcL4JHu4AJ5pJCGbwRwSnTlJnQ3nY+G1A4lvnBeyP4p9DsO0Y iezMmLl8V0383MPPRFkVFUe8vH+mXux08zLyX1sGWTldscz1Fy0NibaWzj2c2rq+Iyw9 +2hi1puysxHrg1Jod+slN3qpmORM5/wdjagkveJLrsAJC6lKUUAYi7vhTAXPVVDgR+xi Sbjw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g3-v6si2088787plt.208.2018.11.11.12.02.53; Sun, 11 Nov 2018 12:03:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731012AbeKLFuD (ORCPT + 99 others); Mon, 12 Nov 2018 00:50:03 -0500 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:51254 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730795AbeKLFsd (ORCPT ); Mon, 12 Nov 2018 00:48:33 -0500 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gLvst-0000oM-JS; Sun, 11 Nov 2018 19:59:03 +0000 Received: from ben by deadeye with local (Exim 4.91) (envelope-from ) id 1gLvsV-0001fr-Ej; Sun, 11 Nov 2018 19:58:39 +0000 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, "Linus Torvalds" , "Peter Feiner" , "Greg Thelen" , "Mike Kravetz" , "Andres Lagar-Cavilla" , "Cannon Matthews" , "Michal Hocko" Date: Sun, 11 Nov 2018 19:49:05 +0000 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) Subject: [PATCH 3.16 226/366] mm: hugetlb: yield when prepping struct pages In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.61-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Cannon Matthews commit 520495fe96d74e05db585fc748351e0504d8f40d upstream. When booting with very large numbers of gigantic (i.e. 1G) pages, the operations in the loop of gather_bootmem_prealloc, and specifically prep_compound_gigantic_page, takes a very long time, and can cause a softlockup if enough pages are requested at boot. For example booting with 3844 1G pages requires prepping (set_compound_head, init the count) over 1 billion 4K tail pages, which takes considerable time. Add a cond_resched() to the outer loop in gather_bootmem_prealloc() to prevent this lockup. Tested: Booted with softlockup_panic=1 hugepagesz=1G hugepages=3844 and no softlockup is reported, and the hugepages are reported as successfully setup. Link: http://lkml.kernel.org/r/20180627214447.260804-1-cannonmatthews@google.com Signed-off-by: Cannon Matthews Reviewed-by: Andrew Morton Reviewed-by: Mike Kravetz Acked-by: Michal Hocko Cc: Andres Lagar-Cavilla Cc: Peter Feiner Cc: Greg Thelen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Ben Hutchings --- mm/hugetlb.c | 1 + 1 file changed, 1 insertion(+) --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -1546,6 +1546,7 @@ static void __init gather_bootmem_preall */ if (hstate_is_gigantic(h)) adjust_managed_page_count(page, 1 << h->order); + cond_resched(); } }