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 E7D54C04FFE for ; Wed, 8 May 2024 09:06:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 74C3F6B00C2; Wed, 8 May 2024 05:06:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6FC7A6B00C3; Wed, 8 May 2024 05:06:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5C2BA6B00C4; Wed, 8 May 2024 05:06:24 -0400 (EDT) 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 3EB156B00C2 for ; Wed, 8 May 2024 05:06:24 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id CA0F5161077 for ; Wed, 8 May 2024 09:06:23 +0000 (UTC) X-FDA: 82094647446.11.06AF630 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf12.hostedemail.com (Postfix) with ESMTP id 1EDCE40004 for ; Wed, 8 May 2024 09:06:21 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf12.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1715159182; 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; bh=k7fOj5XX5IEafFwIhZQSIXcjl1m++wsm71+UhpUgqmg=; b=vp6l7N3xc7kAw+pd+3AGOUtzP0IRN6MbqP8CmmwnAs+UTdf4VjfvxE8NFw2xZ/lt38cApE tHR3A6wsX4Xm+sw49knmxH73WiMFVaxYv7casrXKNbSjH9fDZcSNgWR9MmOhAzcCwYZrvp oryE3qzjgfUkNXv/bUMav2DcvHqh7Pc= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf12.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1715159182; a=rsa-sha256; cv=none; b=hiqV3HP5Ie+MbAVx5uju5/5Z9ZdslGETwlP52nkbTf1lOVKPGRXD3sk7sMfwKRfCyPUWAj M9EVXRjLLC4adl9oUQ/L6zF5Pz2Jud3DClB9DL+sF4TxtepRVyDqaAP4f8vfAm5r0+sbLs 2j/d+BMzbmuD4/iSiEmyKOsfYJWBqps= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id B40161063; Wed, 8 May 2024 02:06:46 -0700 (PDT) Received: from [10.57.67.194] (unknown [10.57.67.194]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5E2363F6A8; Wed, 8 May 2024 02:06:19 -0700 (PDT) Message-ID: Date: Wed, 8 May 2024 10:06:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/8] mm: move highest_order() and next_order() out of the THP config Content-Language: en-GB To: Baolin Wang , akpm@linux-foundation.org, hughd@google.com Cc: willy@infradead.org, david@redhat.com, ioworker0@gmail.com, wangkefeng.wang@huawei.com, ying.huang@intel.com, 21cnbao@gmail.com, shy828301@gmail.com, ziy@nvidia.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <9576c979-8a11-48e2-aec4-646acf0d8e26@arm.com> <2fcd6dfc-21b7-4e3f-9741-8f0d23d2da5f@linux.alibaba.com> From: Ryan Roberts In-Reply-To: <2fcd6dfc-21b7-4e3f-9741-8f0d23d2da5f@linux.alibaba.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam01 X-Stat-Signature: 666u8fnb73w6ook7qh8pjrqd8tkb7fbp X-Rspam-User: X-Rspamd-Queue-Id: 1EDCE40004 X-HE-Tag: 1715159181-275982 X-HE-Meta: U2FsdGVkX1/6tW6lxCl4i0nhPejxlu8inTPTYdRQMFybeaWJWnJ11jf1G6thCs/uxsYKLgJWvrkdK1BvnUgUc2ncZLHwYaJALAXM3Jj6W5X9623YIhf7LEirV9m0zxct2pPi4HHcHzT7/6hRp3FHfVtgOdRQGQ6sGdCKw1qunI25lb/4lOK4n8a4Zuv34u2+Iun4fuq/hh7MiNFRNHOpW6+yj4heBtSaXUA/sUYLtn5Tdq375ZX+IJ91sn/VmEXNfN6E1lGLg+fZovgR77oC/cgQK+GeY+xJ9nUe/IRfMHyKzqiEkZgZiOkGDLVO6V6ti/2p3lwiMDBgzEooBxWrQFUI5uFahMLvRnWISkTdf0X2o++lUbs4jpQRa82hJS+Gv+htv/QrRr9Uxl9+J1CBkVpZ1Pzeavtj9x1HnIAB0Py08sJj6yy3VObGd6y5mX6KCDlEZXN3m7TNsEYY67H7qYx9ZCRCetPgVKJbV3hUfLO1yAyDqP/4qdQPKkOG8H5vy2iJpqNuXGyvoTJunJArK85G4OZtgP54tezTbdTcShA/+RBLbCWc3byvIwir3ST1UY7zrJfbNP38HzlOozk517NmNWa2UCHSflB6oA30vHRm/qcDCdJY7wZNVNPTXCk5lUPFPulWqoDksbbuIiFyfjtY14xuCz8Sm41mX7mOED830WJ3MCHIQPML3JbhRcHXCGdqcEVf+t22KtBHvjXRzuaSzj6YuXURumq8bSdzObzPiHzMnRZtt6SR7rTxlHdnzoXbWnpFMSgMwbcXNy0AyQGRhknR4LGFFEepeiBIWp8ranT7h0PIMraGP1IOmGcTFjaisqrkIZvNdd3CoH+zJ/L7LmDhTL5sQxfBNIS6KH5u3mHRkZLpYX1SIS/aatzsYbTLjx4so8uPojkUPqnmL2zq+voTXxkjiqJkzp6+y+tcG2RJspjk4lXBftAKfkQXzGCGGBUPM7NRQGlor70 P6NBM06k 8O8SXlw4T9rfpktQibIBvQF3u7DeFrk5tNYtCI0B+mXhq8dOW2mudYHFGD6TYk3WszbIbgA+xfHPRqESBoPK9Df8j662nXZuAIrPgH2hSjWgVXtAXYiE1OpRRg5KUFarl8zkWKoF4OjafRKdRp7R7qinUoCFweXOF7xm4atRg5uFGC9PjR4ASklnk3IodpVE/t4gy 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 08/05/2024 03:13, Baolin Wang wrote: > > > On 2024/5/7 18:21, Ryan Roberts wrote: >> On 06/05/2024 09:46, Baolin Wang wrote: >>> Move highest_order() and next_order() out of the CONFIG_TRANSPARENT_HUGEPAGE >>> macro, which can be common functions to be used. >> >> Sorry if I haven't kept up with the discussion, but why is this needed? I >> wouldn't expect a need to iterate over orders if THP is compile-time disabled >> because we will never try to allocate THP? > > Cause I don't want to add some dummy functions to avoid building errors if > CONFIG_TRANSPARENT_HUGEPAGE is not enabled in patch 6. Another thought is that > the pagecache can also allocate a large folio even when THP is not enabled, so > these helpers may be used in the future (not sure though). OK, I'll admit I haven't looked at the latter patches yet - I'd like to conclude on the interface and mapping/alignment strategy first. But it wasn't necessary to access these functions for the anon/private case without CONFIG_TRANSPARENT_HUGEPAGE, so I'm wondering why it's needed for shmem case. I would expect that they don't need to be defined at all. > > Anyway, I also have no strong perference for this patch, below dummy functions > can also work for me: > diff --git a/include/linux/huge_mm.h b/include/linux/huge_mm.h > index c15bebb2cf53..7aa802ee2ce5 100644 > --- a/include/linux/huge_mm.h > +++ b/include/linux/huge_mm.h > @@ -586,6 +586,16 @@ static inline bool thp_migration_supported(void) >  { >         return false; >  } > + > +static inline int highest_order(unsigned long orders) > +{ > +        return 0; > +} > + > +static inline int next_order(unsigned long *orders, int prev) > +{ > +        return 0; > +} >  #endif /* CONFIG_TRANSPARENT_HUGEPAGE */