From: Mike Rapoport <rppt@kernel.org>
To: Stephen Eta Zhou <stephen.eta.zhou@outlook.com>
Cc: "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] mm: optimize memblock_add_range() for improved performance
Date: Fri, 7 Feb 2025 16:58:49 +0200 [thread overview]
Message-ID: <Z6YfqcOx5FACtvae@kernel.org> (raw)
In-Reply-To: <BYAPR12MB32059CFEB36A5FC7D859B69FD5F72@BYAPR12MB3205.namprd12.prod.outlook.com>
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.
next prev parent reply other threads:[~2025-02-07 15:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-05 5:55 Stephen Eta Zhou
2025-02-07 14:58 ` Mike Rapoport [this message]
2025-02-07 15:29 ` Stephen Eta Zhou
2025-02-07 15:58 ` 回复: " Stephen Eta Zhou
2025-02-07 16:03 ` Stephen Eta Zhou
2025-02-09 13:53 ` Mike Rapoport
2025-02-11 3:32 ` 回复: " Stephen Eta Zhou
2025-02-12 7:42 ` zhou stephen eta
2025-02-07 16:17 ` Stephen Eta Zhou
2025-02-07 16:29 ` Stephen Eta Zhou
-- strict thread matches above, loose matches on Subject: below --
2025-02-07 15:32 Stephen Eta Zhou
2025-02-05 5:48 Stephen Eta Zhou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z6YfqcOx5FACtvae@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=stephen.eta.zhou@outlook.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox