All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Peng Zhang <zhangpeng.00@bytedance.com>
Cc: akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] memblock: Make finding index faster when modify regions.
Date: Thu, 19 Jan 2023 15:00:51 +0200	[thread overview]
Message-ID: <Y8k/AxLAu2sXcacc@kernel.org> (raw)
In-Reply-To: <49b867c1-2b68-c034-9f60-b26a77ff326a@bytedance.com>

On Mon, Jan 16, 2023 at 04:40:47PM +0800, Peng Zhang wrote:
> 
> 
> 在 2023/1/16 15:37, Mike Rapoport 写道:
> > On Mon, Jan 16, 2023 at 11:17:40AM +0800, Peng Zhang wrote:
> > > 
> > > 
> > > 在 2023/1/15 22:02, Mike Rapoport 写道:
> > > > Hi,
> > > > 
> > > > On Fri, Jan 13, 2023 at 04:26:58PM +0800, Peng Zhang wrote:
> > > > > We can use binary search to find the index to modify regions in
> > > > > memblock_add_range() and memblock_isolate_range(). Because the
> > > > > arrangement of regions is ordered. It may be faster when there are
> > > > > many regions. So implemented a binary search and a new macro to walk
> > > > > regions.
> > > > 
> > > > Did you see a measurable speedup with this optimization?
> > > > I'm not in favor of micro-optimizations that complicate code.
> > > > 
> > > Thank you for your reply. I haven't measured this patch yet, theoretically
> > > this small optimization might be difficult to observe.
> > > If you think this patch complicates the code, you can ignore this patch.
> > > 
> > > These three patches are independent and they can be applied independently.
> > > The logic of the third patch is very simple. It will not complicate the
> > > code. It is tested by the default configuration of qemu. The total number of
> > > iterations of memblock_merge_regions() in the third patch is reduced from
> > > more than one thousand to more than one hundred, this is only in the case of
> > > a small number of regions. Can you consider the third patch?
> > 
> > Can you please send the numbers and show how did you obtained them?
> > 
> > > Sincerely yours,
> > > Peng.
> > 
> I obtained the numbers like this:
> 
> void memblock_merge_regions(struct memblock_type *type) {
> 	static int iteration_count = 0;
> 	static int max_nr_regions = 0;
> 
> 	max_nr_regions = max(max_nr_regions, (int)type->cnt);
> 	...
> 	while () {
> 		iteration_count++;
> 		...
> 	}
> 	pr_info("iteration_count: %d max_nr_regions %d", iteration_count,
> max_nr_regions);
> }
> 
> Boot the kernel by qemu.
> The folowing numbers is the last output.
> 
> master branch:
> iteration_count: 1762 max_nr_regions 41
> 
> patched:
> iteration_count: 182 max_nr_regions 41

The numbers that indicate what speed up your patch achieves should be a
part of the changelog. It would be great if you could test it on a real
machine and measure the actual time saved by your changes.

> If max_nr_regions is larger, the difference will be more.
> 
> Thanks.
> 
> Sincerely yours,
> Peng

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2023-01-19 13:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-13  8:26 [PATCH 0/3] Some small improvements for memblock Peng Zhang
2023-01-13  8:26 ` [PATCH 1/3] memblock: Make a boundary tighter in memblock_add_range() Peng Zhang
2023-01-13  8:26 ` [PATCH 2/3] memblock: Make finding index faster when modify regions Peng Zhang
2023-01-15 14:02   ` Mike Rapoport
2023-01-16  3:17     ` Peng Zhang
2023-01-16  7:37       ` Mike Rapoport
2023-01-16  8:40         ` Peng Zhang
2023-01-19 13:00           ` Mike Rapoport [this message]
2023-01-13  8:26 ` [PATCH 3/3] memblock: Avoid useless checks in memblock_merge_regions() Peng Zhang
2023-01-17  7:31   ` Peng Zhang
2023-01-19 13:04   ` Mike Rapoport

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=Y8k/AxLAu2sXcacc@kernel.org \
    --to=rppt@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=zhangpeng.00@bytedance.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.