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 0F5F1C02199 for ; Sun, 9 Feb 2025 13:54:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 694526B007B; Sun, 9 Feb 2025 08:54:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 644976B0083; Sun, 9 Feb 2025 08:54:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 534216B0085; Sun, 9 Feb 2025 08:54:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 35EE76B007B for ; Sun, 9 Feb 2025 08:54:09 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A9D3D12154F for ; Sun, 9 Feb 2025 13:54:08 +0000 (UTC) X-FDA: 83100550176.19.F251B3F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf10.hostedemail.com (Postfix) with ESMTP id 03F39C000E for ; Sun, 9 Feb 2025 13:54:06 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VyDw41iR; spf=pass (imf10.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739109247; a=rsa-sha256; cv=none; b=ncnz6z3XT4J3o6SQU19blmdTvLIavKzRGGl+apHVmE42dwjZbfzEDoo9OWNbbEf2mb0EOm N1RS16bF6z5AUabE5S32L8KfYAzgKqzK9TsGl8GtBEubqQlX1vP56I2DcLbj2X1QBLlNVH k61xcPhLoMqJaJi3P6JkYHcYVq6JBDE= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=VyDw41iR; spf=pass (imf10.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@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=1739109247; 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=SRPD6Qet70YrLUuhV9BqbbGtjV2/ciKdbgxX9vP9hpM=; b=ybV7o2YGc7CKdwaXt5fn5ZOUfvek5NUNc5npzz13Tgk58kepVsVC5sERhrS0SUHPhcQNVh qD36usLTTKFKQrYQWz5h3Hp/ZNfXTdu6OC9kAh23EHPEzWN0cHczHOShmGLmn5I4Q0iWpe LA/ovLTmGAPVL6xVfg62vmb4EpLPgDA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 60C1A5C5742; Sun, 9 Feb 2025 13:53:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EC288C4CEDD; Sun, 9 Feb 2025 13:54:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1739109245; bh=teKGPj586TuQGXQSHU7KVCjMSBPyuJFyC/BbjoOcrXk=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VyDw41iRPZAsEm1WHz1XCBtbskTEUkwv9gdoq/3byK/OJ4eRCpkzDRoE4zSqZvUEx 0J2RUx8xBVDLd2N/Jvn9LUfFkHNXubExpix+nyeaGx3IIqGYWbj6VcZ1gyopPDUD6v ABUmj3tmFVBF4qBPz9yVC3s1NHxX3QvkkdEiYVN3yip7AsPBFRIOPj8vPfDyIlAqV7 o5mj2AB8zmcfRUUny2BQAxW/dOTYNQpOBMvFZPoa3gB6YMN8cWvGZx0OZXDlamJl76 b5qNXpTbb8z506ALw47wMiwu4AfpBmK59WXNIVWOx/nNsCCJ64gSqx8aIxz6KyIr2o OUDUxeQTWySrg== Date: Sun, 9 Feb 2025 15:53:54 +0200 From: Mike Rapoport To: Stephen Eta Zhou Cc: "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" Subject: Re: =?utf-8?B?5Zue5aSNOiBbUEFUQ0g=?= =?utf-8?Q?=5D?= mm: optimize memblock_add_range() for improved performance Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Stat-Signature: k6b6pacqtg1hy58jng8z8f3ku1d89oub X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 03F39C000E X-Rspam-User: X-HE-Tag: 1739109246-430274 X-HE-Meta: U2FsdGVkX19ys9QKzyc5gYr9yYfmnwEPxpvKe5Qm/zVxBz8qmeOzmq9b5TNmQ2yo4oxxTqCaJlBwkU1Dt17EBjrut9fJxjphYCmWs53E/DdEJeJ7RR+QTpCA5GG7OmFi7wfVhMqiM7X4oqIU9wmu5Je3IDZVPoIroIL023SrB+GwIOc+MlBWTnxPe6CmSCk4lDONGEvaENZ3R9YMsbG0NdU1+smebrsBm2zrm6reuoO2OtXUZ7W3NErUzvPWPI8CtGrb1Yh9m7LOOWmYDCgPBn9cxn2zxNilkRYuB2OajGueemG6b95McftJG+CiXEL85+3RiiALeCZt7GdzKpPM7wHVuY3QUkebvb7yQLnU/6+MJvg2vacv0LONYvUhgcmdGa8w9YEIgalogsVRqaSzprPxuDi2MsbbpybIcVhAJR4l/gxRfs5nI4KG3A+oppjirCYAgYiMjMseoQ17iOHXI1AkLPAvk+M8TIcgjp9A+L0Dp4wHctKfT2QyttAfpH1+iiyFDvWNYtLNFk2YrGrFStm/6MAexb1so1i2iFVWPazFLKZXmphZ7F3QMUwC8mH/0ZxJEbNOqvzXDMmfdrB8mo0tUs801gwTkPZSDmk8xImSTAtW3i4tbsnl4SQMYMrlAFIIocqxWH6DtabZJRF2E/XigJAbyGiz+swE1Wiho+lIgS+9CemlIP2MhSFTwelbXkiegjzajAs856RNvf6bQ7yqCTvK2AkW7jpcFvhFNnlHtdaM0SJrcKp43uN9vbhaAtdi+xgB0WyvAx+wlPHsiKNUglEgWojoWk+XPxSIt/eCqSItu7IRdjyQekjCIbK1YxkoFqtNiwyiEginxIRFw5NGS78rNRFH3SgdjZVXLtE/fhSdLu29DcEC/GxO6StGXevscxEKdU55sM0/tFO8wyjHIXl1R9HTlhf+6UzyRA4MYy/V9xJaavwBsnR5CgRWm7EvDFP1PA4jZ7bJnnG XVSGiJjs yPTSPN1dWpFkH2QqIPzURUCt1ufOrI0VhhZqio03w8Vqllcnlgk46OIzPMyT137/f+CzDEvVT/pZhqEdeqQMIFcrPrgpYrdTPRWf+GI2yVJBo2UGRV3MQfwlhNHAbhQrXBHarthwv/NrwnDF8ODrUSwfDy53ob55lzQ0XbUmBFoCBjbi+nBT24cMCcRpmpF/7LBcXj/JYviBCva0xoICX/c4kiZK1hQrBHLTuyN8XDH0EezziI0Dm9/xfDJGUwnavPOVv/J/26ovXl89zQEW5ji2s0vSXcn+sno061Zdu/+YI0S92Luc2VwCnk/cgqzEqetlyUTx/I9z1MzGFs8Y/zpUTt8sYrZSWp4rLCFGbcrUgmWGEB2HcTfGoQxTtcetiP6CRtkvnXEejWAOtwnHnmcUpuwf5pXoA2qfeCiMbEV+6iofr+Q+LLOAEzcrSbl2THSchSUQ5C0tIA+b6xwSZ8HU0DoHRipjTix/WDkvliKALNYjVcYFPqyKPKi2jmWRTbQ8xq4nZv0SmZChhBbJo8wopV7vldV10pJD3kC551kQXzso= 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: Hi Stephen, Please don't top post on Linux kernel mailing list. On Fri, Feb 07, 2025 at 04:03:31PM +0000, Stephen Eta Zhou wrote: > Hi Mike, > > Given the concerns raised, I would greatly appreciate your guidance on > whether you think it's worthwhile for me to continue with this approach. > Should I proceed with further refinements and testing, or would you > recommend a different direction for optimization? Your input will be > invaluable in ensuring this patch meets both performance and stability > goals. I doubt any optimization for memblock_add_range() will really improve boot time and even produce a measurable speed up. With all the fragility and potential of breakage, I don't think it's worthwhile to attempt optimizations there. > Best regards,   > Stephen > ________________________________________ > 发件人: Mike Rapoport > 发送时间: 2025年2月7日 22:58 > 收件人: Stephen Eta Zhou > 抄送: akpm@linux-foundation.org ; linux-mm@kvack.org ; linux-kernel@vger.kernel.org > 主题: Re: [PATCH] mm: optimize memblock_add_range() for improved performance >   > Hi Stephen, > > On Wed, Feb 05, 2025 at 05:55:50AM +0000, Stephen Eta Zhou wrote: > > Hi Mike Rapoport、Andrew Morton > > > I have recently been researching the mm subsystem of the Linux kernel, > > and I came across the memblock_add_range function, which piqued my > > interest. I found the implementation approach quite interesting, so I > > analyzed it and identified some areas for optimization. Starting with > > this part of the code: > > > > if (type->cnt * 2 + 1 <= type->max) > >       insert = true; > > The idea here is good, but it has a certain flaw. The condition is rather > > restrictive, and it cannot be executed initially. Moreover, it is only > > valid when the remaining space is (2/1) + 1. If there is enough memory, > > but it does not satisfy (2/1) + 1, the insertion operation still needs to > > be performed twice. > > The code in memblock_add_range() is very fragile, and many attempts to > remove the second pass that looked correct at the first glance failed for > some corner case. > > Unfortunately, it's impossible to capture all possible memory > configurations and reservations in the memblock test suite, so even it it > passes, there is a chance the kernel will fail to boot on an actual HW. >   > > - Before the patch: > >   - Average: 1.22% > >   - Max: 1.63%, Min: 0.93% > > > > - After the patch: > >   - Average: 0.69% > >   - Max: 0.94%, Min: 0.50% > > > > These numbers do not represent what's actually interesting: the boot time > speedup. > > -- > Sincerely yours, > Mike. -- Sincerely yours, Mike.