From mboxrd@z Thu Jan 1 00:00:00 1970 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 8B63FCD1284 for ; Thu, 4 Apr 2024 22:22:15 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 22AE66B0099; Thu, 4 Apr 2024 18:22:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1DB916B009C; Thu, 4 Apr 2024 18:22:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0A30F6B009D; Thu, 4 Apr 2024 18:22:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id DDF926B0099 for ; Thu, 4 Apr 2024 18:22:14 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id A58B4A167A for ; Thu, 4 Apr 2024 22:22:14 +0000 (UTC) X-FDA: 81973273788.16.F9698B9 Received: from mail-vs1-f52.google.com (mail-vs1-f52.google.com [209.85.217.52]) by imf22.hostedemail.com (Postfix) with ESMTP id EAC0DC000F for ; Thu, 4 Apr 2024 22:22:12 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lQG0eH1O; spf=pass (imf22.hostedemail.com: domain of fvdl@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712269333; h=from:from:sender: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:in-reply-to:references:references:dkim-signature; bh=5Pic4NZdzlP4xXihBtUAg9zgkAtIAqZuKoS+pSv1G+o=; b=IpVUwjGxegGzsiHehPQrJ/XYhan9c2jynMTqwdNm9liCxn1iySKKznmELtYMsujV/FFb4F snA9dEVTvYcd80XFlDSYeOF8WIvvnkhtlCjVmoH6GyoC/DZ9Lv8a9SKOf6FUc70aemarX1 LUVkwy32/6dIno9mC5KwBHGgso9vWc4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712269333; a=rsa-sha256; cv=none; b=wJRMTmfKmdb/LuafR+CNM4LyydjLQypYq607clKYlXadDqDDl6bNpqe0ZDApZCcLjkaNMl J8eD4IUjvpZhPQ4Q70mW/9wHiVrmyGdqQDFIg9K0Oy3uI9Jh2BEGwF5DTsXDDkMLye7EX6 AAEUuFYOK5OAimvXRbtCWxC7WlBhFko= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=lQG0eH1O; spf=pass (imf22.hostedemail.com: domain of fvdl@google.com designates 209.85.217.52 as permitted sender) smtp.mailfrom=fvdl@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-vs1-f52.google.com with SMTP id ada2fe7eead31-479d6a85be8so137264137.3 for ; Thu, 04 Apr 2024 15:22:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1712269332; x=1712874132; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5Pic4NZdzlP4xXihBtUAg9zgkAtIAqZuKoS+pSv1G+o=; b=lQG0eH1OiTxnU7MiTP89BOjZzeEhnyr9P9a5ETnq5Xxd4IsySRcfACjvPPw8ALw20+ DHGLmDc2E2nlHnNZDUtbTZjdPoYKPTpwBnCI7aThEs9znuebI/tlN+4yAKCMd2um5XFN ZweJotG+2XO3duph+qh2FWVscudRKF9mFsc3XyKhCGJF3uhj73AawI02L9rra0Qt+NY0 v8YhgTJnLqIUng5u9qqApmiZpdoVxBPOLvxsHdXjTqdkHv4mZcdVvLpMeHzAs6sg8mGt P4PmPxLPaPEjidPHA+/Oe8/z5HAeROobIC3LMR7K5orvdS2bEQLS9COUGzB9Mhe0URB4 aI8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712269332; x=1712874132; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5Pic4NZdzlP4xXihBtUAg9zgkAtIAqZuKoS+pSv1G+o=; b=tw4aK7F4HpJ691wpMC6kF28KA9oN7KRSh78YfUm3fMBnw36OwhMnSU9w/miw7LsPGe yeqNOC4eYewjrhINUGHd+p/PH71GC/RzIV5GvKDmH+j03GNxbKncJJDhphMUSDwM1LOu ldKrYNQZGSEVEawHxRcwnPu2T9NzOmWXH4RTj388qLnHzeCNLf4F3Bc3EKpJcenXBwpU dudMTB61WGrGGr2dZWkzmYDa4RfnClT23hvYD6q3SE3DtffX7zBZxO3J4OnP9NRyk6fR hXjJIqPnt36qJmRqL53r+5Mr3SQIFIfDHDIh6e0RVN3ZpV55LSfJ2H/op0hAfANlBMdG GNPQ== X-Gm-Message-State: AOJu0YxcOGUj716VuSTaiqncKJly5DsmeUMhRdk6ihaE3o1wmwPU3FHG S/m+WKGAjs/0Wz5WSlyO4HqoHe2O6Bj5JvNKMBGCfCeclpkjNLdF2zatxYTfwuz9hUMkTjvSheo wc/hUGa1OsND3Z//3Dzw7Vwgo++cb+A+FBGQC X-Google-Smtp-Source: AGHT+IH6WxZXuaQ2KDDgVGD+4L4UibBW1FPLrkLrszFYU+BaDE+DPoJY6k+LqcB6+bN/1Z2XrXPyYRmAf8TxO71oCjM= X-Received: by 2002:a67:fa55:0:b0:478:99a3:6fd0 with SMTP id j21-20020a67fa55000000b0047899a36fd0mr4023682vsq.17.1712269331896; Thu, 04 Apr 2024 15:22:11 -0700 (PDT) MIME-Version: 1.0 References: <20240404162515.527802-1-fvdl@google.com> <20240404162515.527802-2-fvdl@google.com> In-Reply-To: From: Frank van der Linden Date: Thu, 4 Apr 2024 15:22:00 -0700 Message-ID: Subject: Re: [PATCH 2/2] mm/hugetlb: pass correct order_per_bit to cma_declare_contiguous_nid To: David Hildenbrand Cc: linux-mm@kvack.org, muchun.song@linux.dev, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, Roman Gushchin Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: jac1j5pge5y53iwswmjgxp6fhhi9ixm8 X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: EAC0DC000F X-Rspam-User: X-HE-Tag: 1712269332-755084 X-HE-Meta: U2FsdGVkX18U+U/TY7cNMvPXo+AJBV1LgKqwqNYcccazh7cIaq9DfoeFXjXsfxSfnB0F8VYWwVud9wuNffeOkX0DtcjMRvIrFO+TtQMVWdxdvSrGKNFg3Frwx/+y/TU/35Gfc77v8YFeTG+jnGmmsq8s+EWsl70gQruzfEcE+DO5kMB7bH7ivDk0i2adJYcQXrqdVPlNYQnq3I1voDDPbsecsTlUpQf+gnBTeynqDVN862WFqZfHyKgJhHcMkNJYlAGAF1KNZhFsL+hMwduhGGr3UhbbyhKKfO7Rj5bsO+roGtRaTU1aoeaesXHVqRVR7Cig3QDEeknzkgpWy+FMbiehyAuFNUM6sPtn1DsCsBqQmBfYGpQCbOrwvgGF75OedHofCeL+FomjEfXUEdCXWsDUiYMO130Bu2rYO5JlQrPk+xWr017B1vx37O0Q+1dXfVn9LgGO1fniLog7acmZwzSJXL8UxGzTMq3T6b8eLY64FKzCp5QfLZE6l+qe2PbPTdvyYey5REtBszzL7LRaahF4PFrXmbQ5Ll+nPxst9SguCHu1cP+sjgACSfVORhY9zhZ2R/P4l3Xn4Ap74B0cj8xi70UFmN0IDXnHipHWEWjLZM23B1TC2Q68W9hmq5T4Ax8sC4YQM7Yrdk8osG7/EIwaZd0NRFZKBBJdpWLODKUSi7utJR8K/LZnfvbMQZlQR+QM9MOn0wuGUbLImb2SCZ1paNV8X8KRfZ3j2kp936xe3WtyDNNNxqDEcmRsI/gy2lGaOGDSQB0k6l/bTeLVmFm3O/mdR42YDJUJRh9QwBBy81Ax6cE8rE68QDrwVtaYQZItZejaM3ku9FhO0e6J9SzD7jiSCyTNawlxgJM3eEq2zsOId3dSOi2oyRcgl5OiRjT7UdqLBXDK3RNZbHcIB1Ho8X22Ku9qsT8q8WkrqUGJ8J6IQiFd0aQCs6dsnLQXT2me2/E6nML9DDnRCi5 Dn2Rq58s 1bjmIN1tmsVv7NPXZaLGS8h2TUbtF9ZLqYKf6JskCspZjNVqeCBny2qF5frGfeEYXDEsb2S/OF7pEZ5ruY0RQhwpKG9bgoY//tBq1gLdqRBiqkxFieh299Uxkk9S75o9YIsemIOmchndxDNjj74OBIRXbBHXZVrEkK9V/hZPMWJWxZode2gwaIJuwyHgVLpMPlNrxazyEIK6/ZttKmyjCUQRULhUtNz7meSkJ2AxZUqrdZvxd/gdKq69e1lMN+j6aThweXnfdvjsvmgUqRUiOdaO+iTFlD/nxu49M7U9SzVZRZa5CAhmD4yITiWlpEns4ueK1 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Apr 4, 2024 at 2:44=E2=80=AFPM Frank van der Linden wrote: > > On Thu, Apr 4, 2024 at 1:13=E2=80=AFPM David Hildenbrand wrote: > > > > On 04.04.24 18:25, Frank van der Linden wrote: > > > The hugetlb_cma code passes 0 in the order_per_bit argument to > > > cma_declare_contiguous_nid (the alignment, computed using the > > > page order, is correctly passed in). > > > > > > This causes a bit in the cma allocation bitmap to always represent > > > a 4k page, making the bitmaps potentially very large, and slower. > > > > > > So, correctly pass in the order instead. > > > > > > Signed-off-by: Frank van der Linden > > > Cc: Roman Gushchin > > > Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugep= ages using cma") > > > > It might be subopimal, but do we call it a "BUG" that needs "fixing". I > > know, controversial :) > > > > > --- > > > mm/hugetlb.c | 6 +++--- > > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > > > index 23ef240ba48a..6dc62d8b2a3a 100644 > > > --- a/mm/hugetlb.c > > > +++ b/mm/hugetlb.c > > > @@ -7873,9 +7873,9 @@ void __init hugetlb_cma_reserve(int order) > > > * huge page demotion. > > > */ > > > res =3D cma_declare_contiguous_nid(0, size, 0, > > > - PAGE_SIZE << HUGETLB_PA= GE_ORDER, > > > - 0, false, name, > > > - &hugetlb_cma[nid], nid= ); > > > + PAGE_SIZE << HUGETLB_PAGE_ORDER= , > > > + HUGETLB_PAGE_ORDER, false, name= , > > > + &hugetlb_cma[nid], nid); > > > if (res) { > > > pr_warn("hugetlb_cma: reservation failed: err %= d, node %d", > > > res, nid); > > > > ... I'm afraid this is not completely correct. > > > > For example, on arm64, HUGETLB_PAGE_ORDER is essentially PMD_ORDER. > > > > ... but we do support smaller hugetlb sizes than that (cont-pte hugetlb > > size is 64 KiB, not 2 MiB -- PMD -- on a 4k kernel) > > Right, smaller hugetlb page sizes exist. But, the value here is not > intended to represent the minimum hugetlb page size - it's the minimum > hugetlb page size that we can demote a CMA-allocated hugetlb page to. > See: > > a01f43901cfb ("hugetlb: be sure to free demoted CMA pages to CMA") > > So, this just restricts demotion of the gigantic, CMA-allocated pages > to HUGETLB_PAGE_ORDER-sized chunks. > > - Frank Just to clarify what I'm saying here: the restriction of the size you can demote a CMA-allocated gigantic page to was already there, my patch doesn't change anything in that regard.