Message-ID:
 <BYAPR12MB320544222BA694E050BCF5AAD5FC2@BYAPR12MB3205.namprd12.prod.outlook.com>
Date: Wed, 12 Feb 2025 07:42:37 +0000
From: zhou stephen eta <stephen.eta.zhou@...look.com>
To: Mike Rapoport <rppt@...nel.org>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-mm@...ck.org" <linux-mm@...ck.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject:
 Re: 回复: [PATCH] mm: optimize memblock_add_range() for improved performance

Hi Mike

> 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.

I appreciate your previous feedback and, as you suggested, I initially agreed that optimizing memblock_add_range() might not have a significant impact on boot time. However, after conducting some benchmarks, I found that the optimized version runs approximately 5 milliseconds faster compared to the current implementation.

I’m unsure whether a 5ms difference is meaningful in the early boot stage, which is why I wanted to reach out and discuss it with you. If this level of improvement is considered beneficial, I am willing to extend my testing to various physical devices to ensure that the optimization works correctly across different architectures.

Also, I’d like to share that this is my first time modifying the Linux kernel, and I feel a great sense of accomplishment from this experience. I really appreciate the opportunity to learn from this process and from the insights shared by experienced developers like you.

This could be a long-term effort, and I’d love to hear your thoughts on whether it’s worth pursuing further.

Looking forward to your insights!

Best regards,
Stephen
________________________________________
From: Mike Rapoport <rppt@...nel.org>
Sent: Sunday, February 9, 2025 21:53
To: Stephen Eta Zhou <stephen.eta.zhou@...look.com>
Cc: akpm@...ux-foundation.org <akpm@...ux-foundation.org>; linux-mm@...ck.org <linux-mm@...ck.org>; linux-kernel@...r.kernel.org <linux-kernel@...r.kernel.org>
Subject: Re: 回复: [PATCH] mm: optimize memblock_add_range() for improved performance
 
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 <rppt@...nel.org>
> 发送时间: 2025年2月7日 22:58
> 收件人: Stephen Eta Zhou <stephen.eta.zhou@...look.com>
> 抄送: akpm@...ux-foundation.org <akpm@...ux-foundation.org>; linux-mm@...ck.org <linux-mm@...ck.org>; linux-kernel@...r.kernel.org <linux-kernel@...r.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.

Powered by blists - more mailing lists