Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1001261ybg; Wed, 3 Jun 2020 21:00:27 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzLB9UPGCSFbTr7yJq8r5nt4THM7LGpVDoE2dxVFsDwfv/5YvGdVzuB/x8GmQr4KaqdUtAe X-Received: by 2002:a17:906:370a:: with SMTP id d10mr2146436ejc.433.1591243227348; Wed, 03 Jun 2020 21:00:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591243227; cv=none; d=google.com; s=arc-20160816; b=zoVf+EufRoQTFZpVaVmQggrKvhe6NTWmeb84yop9wM8V/nL4kXaLq1a/jI02FULGcF xXBJBLqmF5OalEuPpfWQPXzXfTpqHwWOPtgq2hmQp8CCcTgKqEb7N92617wSPvw6N7cb qCDk3dOlvPz85WKff23/3vhqpmygc++Gw5esqUoNqzANKgnuGN1BBgq/sH4aEItlQh8C oseNHmKDHPJTndDs2b0+3qKQrQInSqj/de8MRKuF1I055meerkePUE5GGXdWvhToaURp q3ItOAJhDc8ZN4Sufbd3VIp9tIfNJ9snjjtqOncjqKVAQe7vHalOFlFx63eax52eXE6t YdkA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=Z6Q9Wq0yQ9bYp+C/bSDjX1Q1JFM5hLt2P2p/aVt1ixU=; b=jyKb4chFmsBFb1eX+rSO5wVo8KJHec/xVB47gMJPd3a1FrXQVon51ZEYuAxPMBGuBt qq0vIOqItg/0f0pk3kBzaVE0q25CLe7EFZlfRv1twYH141TuGRe5ZJ9R448kfn/NkAA5 5qObBqHkuhKx/T03udlnaiLUOZ9jtKkyORZJwYjFM/JxTHtCOYG4CFmnEbNNVsmgFhtX GiONYjvDakCWGrNdgFOy7ugwaSxCbYDNJ7N0msWrrsxoe1T+eO4Rv8iDIo4wZULhqNFV goyN2mr6i9tf1VbhzJLCUStl6TtwyuMaBJR4LkBWTaKLNCUqnvzWOMg8JBUPdaExPGBF 8ToA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=h2Mvt9jh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id x26si980027edv.448.2020.06.03.21.00.02; Wed, 03 Jun 2020 21:00:27 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2020-01-29 header.b=h2Mvt9jh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726704AbgFDDzR (ORCPT + 99 others); Wed, 3 Jun 2020 23:55:17 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:33686 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725959AbgFDDzQ (ORCPT ); Wed, 3 Jun 2020 23:55:16 -0400 Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0543qUMV129253; Thu, 4 Jun 2020 03:54:52 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : mime-version : content-transfer-encoding; s=corp-2020-01-29; bh=Z6Q9Wq0yQ9bYp+C/bSDjX1Q1JFM5hLt2P2p/aVt1ixU=; b=h2Mvt9jhAjmuJDQf5LnGjf46WdYyN920Yi6mmXKJiQzn0dRY1fnmYxrAfEQ8xvVraODM FCaR3RGaHPuMiNLN3V3UMpILWWXjH+5QkzOod+P0JGhRUX82gnFmmfahYH9Tz4KIvF21 rwwsVmgzGkDO6c0ywQ0iADNxEkSyXwEQOWouXghyNpTwNfWG8ghtrFRFfALjKy1JZuAK YQ4t5CX7k2lLgdPi8kyXpcQQ7GIcX39wJl1bfi4+RIbMFKqwAk1qw2o1nsIqewJNjWPv 2/I2LMkqT/lHdqaBfsff4vriYFWITse67cL/U7YMoc3DaSOnm8Qvg/i/4jCAJJQeQ/Cg hA== Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by userp2130.oracle.com with ESMTP id 31bewr4eqy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 04 Jun 2020 03:54:51 +0000 Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0543rTBt168559; Thu, 4 Jun 2020 03:54:51 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 31ej0ysgp8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 04 Jun 2020 03:54:51 +0000 Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0543snsW032028; Thu, 4 Jun 2020 03:54:49 GMT Received: from localhost.localdomain (/98.229.125.203) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 03 Jun 2020 20:54:48 -0700 From: Daniel Jordan To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Andrew Morton , Andy Lutomirski , Dave Hansen , David Hildenbrand , Michal Hocko , Pavel Tatashin , Peter Zijlstra , Steven Sistare , Daniel Jordan Subject: [PATCH] x86/mm: use max memory block size with unaligned memory end Date: Wed, 3 Jun 2020 23:54:43 -0400 Message-Id: <20200604035443.3267046-1-daniel.m.jordan@oracle.com> X-Mailer: git-send-email 2.26.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9641 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 phishscore=0 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006040022 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9641 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 bulkscore=0 phishscore=0 suspectscore=0 impostorscore=0 cotscore=-2147483648 lowpriorityscore=0 mlxscore=0 adultscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2004280000 definitions=main-2006040022 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Some of our servers spend 14 out of the 21 seconds of kernel boot initializing memory block sysfs directories and then creating symlinks between them and the corresponding nodes. The slowness happens because the machines get stuck with the smallest supported memory block size on x86 (128M), which results in 16,288 directories to cover the 2T of installed RAM, and each of these paths does a linear search of the memory blocks for every block id, with atomic ops at each step. Commit 078eb6aa50dc ("x86/mm/memory_hotplug: determine block size based on the end of boot memory") chooses the block size based on alignment with memory end. That addresses hotplug failures in qemu guests, but for bare metal systems whose memory end isn't aligned to the smallest size, it leaves them at 128M. For such systems, use the largest supported size (2G) to minimize overhead on big machines. That saves nearly all of the 14 seconds so the kernel boots 3x faster. There are some simple ways to avoid the linear searches, but for now it makes no difference with a 2G block. Signed-off-by: Daniel Jordan --- arch/x86/mm/init_64.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c index 8b5f73f5e207c..d388127d1b519 100644 --- a/arch/x86/mm/init_64.c +++ b/arch/x86/mm/init_64.c @@ -1390,6 +1390,15 @@ static unsigned long probe_memory_block_size(void) goto done; } + /* + * Memory end isn't aligned to any allowed block size, so default to + * the largest to minimize overhead on large memory systems. + */ + if (!IS_ALIGNED(boot_mem_end, MIN_MEMORY_BLOCK_SIZE)) { + bz = MAX_BLOCK_SIZE; + goto done; + } + /* Find the largest allowed block size that aligns to memory end */ for (bz = MAX_BLOCK_SIZE; bz > MIN_MEMORY_BLOCK_SIZE; bz >>= 1) { if (IS_ALIGNED(boot_mem_end, bz)) base-commit: 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162 -- 2.26.2