From patchwork Thu Feb 27 23:02:09 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Thomas Prescher via B4 Relay X-Patchwork-Id: 13995331 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AF8EBC197BF for ; Thu, 27 Feb 2025 23:02:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4B5D4280006; Thu, 27 Feb 2025 18:02:15 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 40DB4280009; Thu, 27 Feb 2025 18:02:15 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 11986280006; Thu, 27 Feb 2025 18:02:15 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DC232280001 for ; Thu, 27 Feb 2025 18:02:14 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 67A121A1F1F for ; Thu, 27 Feb 2025 23:02:14 +0000 (UTC) X-FDA: 83167249788.07.DCC92BC Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf03.hostedemail.com (Postfix) with ESMTP id 88EAB20023 for ; Thu, 27 Feb 2025 23:02:12 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kJ5VjVad; spf=pass (imf03.hostedemail.com: domain of devnull+thomas.prescher.cyberus-technology.de@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=devnull+thomas.prescher.cyberus-technology.de@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740697332; h=from:from:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=DyK6SIv6JjaSYiHFDMxoo4Nn3/AhnmEjdihbjDpvqlo=; b=dohz0j67NY3baKYn3hWVoJife3DH0dEGYpVm84TlRdCi0kOfmTVfCb5ZzjOltAFcaRMoHS qdBDqiE5G7DsumMCPPGKq2/ep88TedhyM+IJLXxs70aaj52LFLzwvccuOYx89U4s6MY+2F keTOYa/UP3pBFe6LAWIpwCV3s21jjwM= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=kJ5VjVad; spf=pass (imf03.hostedemail.com: domain of devnull+thomas.prescher.cyberus-technology.de@kernel.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=devnull+thomas.prescher.cyberus-technology.de@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740697332; a=rsa-sha256; cv=none; b=GXB5SPMzU4rGACleJ8Tcd2rSKXfuuFjewc5NKkkpWZh/1Ss1M5J2knD1sS7JgBH3FaDSni jcIoTnWz0TuirgmiGeIJOSRUcN2W1STM+u7fB0oX8ZmGk3TnOL22AP6ezoX5SIpoX4+ktD U3WNJW/HhZn//E9If158mYCebGhDNw4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 58C0C61126; Thu, 27 Feb 2025 23:02:03 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPS id 89D81C4CEDD; Thu, 27 Feb 2025 23:02:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1740697331; bh=77mfKSU/7bUid7o9jDTk0QDdNak1HyZH2KPQxoAjUqg=; h=From:Subject:Date:To:Cc:Reply-To:From; b=kJ5VjVadIYH14WN9A7Eo5CMk1ngHf+2Z7d2tCXlwfE2L8N9egHE9Lv0Wyd04syAyZ GQiGjCMmvjOzeEAi3BCH0FGEfUjnffDrk/65fwucI2axX2enL34QMb0swYthZDQQpy oY5pRB224vAN7JWaxEwZnrUXQ6uWpktxxWCKIENzzEDQJGYWGnTvg+zb+bJoRd0xjl yyJyocKpv8oQ7qvs2gIkDzKkB5SxrIcWgNldwji/zAjI4mtZ6aekr0PVySCd/COpx1 YLcpPK/P/oYa9edlLnkJBdMtPgVXSjrWs/C7F26S/ymHltJUwNIxGtpPB/wTrlahp6 fIOrN8/LoeAWQ== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6FDFFC197BF; Thu, 27 Feb 2025 23:02:11 +0000 (UTC) From: Thomas Prescher via B4 Relay Subject: [PATCH v3 0/3] Add a command line option that enables control of how many threads should be used to allocate huge pages. Date: Fri, 28 Feb 2025 00:02:09 +0100 Message-Id: <20250228-hugepage-parameter-v3-0-2628e9b2b5c0@cyberus-technology.de> MIME-Version: 1.0 X-B4-Tracking: v=1; b=H4sIAPHuwGcC/33NQQ6CMBAF0KuQrq0pBSy68h7GRZlOaROlTQuNh HB3CysXajKb/5P/ZiERg8VILsVCAiYbrRtyqA4FASOHHqlVORPOeMM4L6mZevQy914G+cQRA8W 2qblWGphEkoc+oLavHb3dczY2ji7M+49Ubu1fLpWUUS3rsxQC2nxXmDsMU6Qjghncw/XzUSHZ6 MQ/OfGV45kTqmvhpIDVTfWLW9f1DRVYK/QPAQAA X-Change-ID: 20250221-hugepage-parameter-e8542fdfc0ae To: Jonathan Corbet , Muchun Song , Andrew Morton Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Thomas Prescher X-Mailer: b4 0.14.2 X-Developer-Signature: v=1; a=ed25519-sha256; t=1740697330; l=2949; i=thomas.prescher@cyberus-technology.de; s=20250221; h=from:subject:message-id; bh=77mfKSU/7bUid7o9jDTk0QDdNak1HyZH2KPQxoAjUqg=; b=9MUeqnBuqLbrQS5045xPrHI4IgCVsWVTUBuVD3OAtqS7we6JJlqgxV8uvskTuQNoPESsrgYVm o84ZIPyr5GTBHpV7LiQWNLpUR+QEgJaYo3w7hpJzfrKF5Aw7i/+vbWK X-Developer-Key: i=thomas.prescher@cyberus-technology.de; a=ed25519; pk=T5MVdLVCc/0UUyv5IcSqGVvGcVkgWW/KtuEo2RRJwM8= X-Endpoint-Received: by B4 Relay for thomas.prescher@cyberus-technology.de/20250221 with auth_id=345 X-Original-From: Thomas Prescher Reply-To: thomas.prescher@cyberus-technology.de X-Rspam-User: X-Rspamd-Queue-Id: 88EAB20023 X-Rspamd-Server: rspam09 X-Stat-Signature: f93x1ip3yi4iy13xg44ase8mb1cyqpkq X-HE-Tag: 1740697332-628056 X-HE-Meta: U2FsdGVkX1/74k7MHVZazCv8KnwFygXatIHcpN0sZ98MR5q5UBl6d4YOERIo/sddi96HwXzirUqatasJ4F4wxZ0urVNTsTpyFdd0fMj6JwiYO0MKsA7P+73EbssmV5hQCnFtU3tBC7BYZkOaGcP6erC59QNbVIOviKo9JOs+2JGvMdKij4LQBpU5tK67+DcJcUQ22eZcoVbzaWBu53bh52MdnujYGokwz+msCj+qKQEjN3RionjQyoG8oP3BT50WG6dDS/EJQVE0di4hjqmhbIcZLM0FYdN45hlmT7XWSvQ/YMK12QflQ8PTm7fT9cqMDfWV5z5WlVoSkKU3nanORq+hcLIcfsJAHYJNEBzxPmCjr0wRQXXToocbRe0jEHG5ha4H0+FsNnQIi7B7d4thMj/jBLNCeL1iAfnEmCoY3TK+k6SiQ1u1E3+VGHnA5BUhL+G1R39/WB9qhflKjLOMfUYksRJgLBsI6jYpWIWzk8hQv2E4TDu9viDo833+wq08/jx14B4NdH7Pa/n/+sxW4MVD/1Kukx1T9RJJ4HQo884qyXyNHV9YcUWgMyXk03C+Rbuwud/GQxQvsu2X+bjr40h5CscHIrrafOFrbAWJvXK6xoTDWwW6EbV/6z6e5qXeVf8XnCdO0a/TsyRBQQsOp2KTsyjqsCQQFYikGH6+6HVCVIgjiSIRu+Rnlf+3p1vh9wa0+qehqywkO8btpIwxt3zbTI7ZYpxVz4BuJhNHhl5vbihgWlpEeY9VcOmHigV0CpKMfTSgQ+kXLVIV/+F1ybNqXUg3Aq9buFwvfvzZFo93+PA44v2kqkFbSd0zS2K2kpCGEtVC/XiuquXV1BlCnanTTytpIIpapp97gqBA7aKSjPLR9+2pIG9qQle2A0XXnOFTTjq1ofWQHPsrVq53c5q8Ge49Ue5E0KUSqUQXNUVD2KTn0u4+/2BwAs0aGLZJaJBZYuJMTCvLprRo9Pf 4p8ChDG6 O/5YVC6PBl1Qzk97p/5PTVax4+6K1pCJr2BTX0RjbYQkfp+BUhOvgaIFdPpZEgD0PeU8cxAzfac7JI84f4dbx6OTdU03jxESQXDR+M3K0Tefrus8gu+VrXAcwBbQA1BdWN26/3cgtQCZSiV9azPOBW77cGjEDyaBPpFuEUHirUkKn+h21ulITghoTkdNtJUlWpQ3Ia9kyZpQExYOScddorZQ/lvlGw8XypLxSYLRp0PTNixCl5BAxJYrsmSEZPYuC+tPP0/UMaPXz9hNGpMfj7bGEE0KwUFcfUeUvWgJvZhydS9SySWvFpGZtzDgVWqLW1Pc1CL9AtWgWQWrMJZGj2hIjOn9UfDWacZ6gl5Wi+vlfDFDXCcZwLzeAsj3055umuREi9NJbfgofF0fRwUlikhayca6YUvWvcpWg9Ke9ORDtd+Sjam1I8oOmsGP1C2meLP1V/WDgfJvxAPX8HZyMl16Urr8SbvrXfkff+shIQ+bQ+oc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000007, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Allocating huge pages can take a very long time on servers with terabytes of memory even when they are allocated at boot time where the allocation happens in parallel. Before this series, the kernel used a hard coded value of 2 threads per NUMA node for these allocations. This value might have been good enough in the past but it is not sufficient to fully utilize newer systems. This series changes the default so the kernel uses 25% of the available hardware threads for these allocations. In addition, we allow the user that wish to micro-optimize the allocation time to override this value via a new kernel parameter. We tested this on 2 generations of Xeon CPUs and the results show a big improvement of the overall allocation time. +-----------------------+-------+-------+-------+-------+-------+ | threads | 8 | 16 | 32 | 64 | 128 | +-----------------------+-------+-------+-------+-------+-------+ | skylake 144 cpus | 44s | 22s | 16s | 19s | 20s | | cascade lake 192 cpus | 39s | 20s | 11s | 10s | 9s | +-----------------------+-------+-------+-------+-------+-------+ On skylake, we see an improvment of 2.75x when using 32 threads, on cascade lake we can get even better at 4.3x when we use 128 threads. This speedup is quite significant and users of large machines like these should have the option to make the machines boot as fast as possible. Signed-off-by: Thomas Prescher --- Changes in v3: - Fix log message (the name of the parameter was incorrect) - Link to v2: https://lore.kernel.org/r/20250227-hugepage-parameter-v2-0-7db8c6dc0453@cyberus-technology.de Changes in v2: - the default thread value has been changed from 2 threads per node to 25% of the available hardware threads - the hugepage_alloc_threads parameter now specifies the total number of threads being used instead of threads per node - the kernel now logs the time needed to allocate the huge pages and the number of threads being used - update the documentation so that users are aware that this does not apply to gigantic huge pages - Link to v1: https://lore.kernel.org/r/20250221-hugepage-parameter-v1-0-fa49a77c87c8@cyberus-technology.de --- Thomas Prescher (3): mm: hugetlb: improve parallel huge page allocation time mm: hugetlb: add hugetlb_alloc_threads cmdline option mm: hugetlb: log time needed to allocate hugepages Documentation/admin-guide/kernel-parameters.txt | 9 ++++ Documentation/admin-guide/mm/hugetlbpage.rst | 10 ++++ mm/hugetlb.c | 67 +++++++++++++++++++------ 3 files changed, 70 insertions(+), 16 deletions(-) --- base-commit: dd83757f6e686a2188997cb58b5975f744bb7786 change-id: 20250221-hugepage-parameter-e8542fdfc0ae Best regards,