From: Wei Yang <richard.weiyang@gmail.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: Wei Yang <richard.weiyang@gmail.com>,
akpm@linux-foundation.org, linux-mm@kvack.org,
Jinyu Tang <tjytimi@163.com>,
Peng Zhang <zhangpeng.00@bytedance.com>
Subject: Re: [PATCH 1/6] mm/memblock: reduce the two round insertion of memblock_add_range()
Date: Mon, 22 Apr 2024 02:55:00 +0000 [thread overview]
Message-ID: <20240422025500.n5542xmrc3zy4qgb@master> (raw)
In-Reply-To: <Zh1FJGOX_GVKxs9J@kernel.org>
On Mon, Apr 15, 2024 at 06:17:56PM +0300, Mike Rapoport wrote:
>On Sun, Apr 14, 2024 at 12:45:26AM +0000, Wei Yang wrote:
>> Current memblock_add_range() does the insertion with two round
>> iteration.
>>
>> First round does the calculation of new region required, and second
>> round does the actual insertion. Between them, if current max can't meet
>> new region requirement, it is expanded.
>>
>> The worst case is:
>>
>> 1. cnt == max
>> 2. new range overlaps all existing region
>>
>> This means the final cnt should be (2 * max + 1). Since we always double
>> the array size, this means we only need to double the array twice at the
>> worst case, which is fairly rare. For other cases, only once array
>> double is enough.
>>
>> Let's double the array immediately when there is no room for new region.
>> This simplify the code a little.
>
>Very similar patch was posted a while ago:
>https://lore.kernel.org/all/20221025070943.363578-1-yajun.deng@linux.dev
>
>and it caused boot regression:
>https://lore.kernel.org/linux-mm/Y2oLYB7Tu7J91tVm@linux.ibm.com
>
Got the reason for the error.
When we add range to reserved and need double array, following call happends:
memblock_add_range()
idx <- where we want to insert new range
memblock_double_array()
find available range for new regions
memblock_reserve() available range
memblock_insert_region() at idx
The error case happens when find available range below what we want to add,
the idx may change after memblock_reserve().
The following change looks could fix it.
diff --git a/mm/memblock.c b/mm/memblock.c
index 98d25689cf10..52bc9a4b20da 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -395,6 +395,7 @@ void __init memblock_discard(void)
/**
* memblock_double_array - double the size of the memblock regions array
* @type: memblock type of the regions array being doubled
+ * @idx: current region index if we are iterating
* @new_area_start: starting address of memory range to avoid overlap with
* @new_area_size: size of memory range to avoid overlap with
*
@@ -408,6 +409,7 @@ void __init memblock_discard(void)
* 0 on success, -1 on failure.
*/
static int __init_memblock memblock_double_array(struct memblock_type *type,
+ int *idx,
phys_addr_t new_area_start,
phys_addr_t new_area_size)
{
@@ -490,8 +492,24 @@ static int __init_memblock memblock_double_array(struct memblock_type *type,
* Reserve the new array if that comes from the memblock. Otherwise, we
* needn't do it
*/
- if (!use_slab)
+ if (!use_slab) {
+ /*
+ * When double array for reserved.regions, we may need to
+ * adjust the index on finding new_array below
+ * new_area_start. This is because memblock_reserve() below
+ * will insert the range ahead of us.
+ * While the insertion may result into three cases:
+ * 1. not adjacent any region, increase one index
+ * 2. adjacent one region, not change index
+ * 3. adjacent two regions, reduce one index
+ */
+ int ocnt = -1;
+ if (idx && type == &memblock.reserved && addr <= new_area_start)
+ ocnt = type->cnt;
BUG_ON(memblock_reserve(addr, new_alloc_size));
+ if (ocnt >= 0)
+ *idx += type->cnt - ocnt;
+ }
/* Update slab flag */
*in_slab = use_slab;
--
Wei Yang
Help you, Help me
next prev parent reply other threads:[~2024-04-22 2:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-14 0:45 Wei Yang
2024-04-14 0:45 ` [PATCH 2/6] memblock tests: add the 129th memory block at all possible position Wei Yang
2024-04-15 15:19 ` Mike Rapoport
2024-04-16 12:55 ` Wei Yang
2024-04-17 5:51 ` Mike Rapoport
2024-04-18 9:02 ` Wei Yang
2024-04-19 3:15 ` Wei Yang
2024-04-24 13:13 ` Mike Rapoport
2024-04-14 0:45 ` [PATCH 3/6] mm/memblock: fix comment for memblock_isolate_range() Wei Yang
2024-04-14 0:45 ` [PATCH 4/6] mm/memblock: remove consecutive regions at once Wei Yang
2024-04-14 0:45 ` [PATCH 5/6] memblock tests: add memblock_overlaps_region_checks Wei Yang
2024-04-14 0:45 ` [PATCH 6/6] mm/memblock: return true directly on finding overlap region Wei Yang
2024-04-15 15:17 ` [PATCH 1/6] mm/memblock: reduce the two round insertion of memblock_add_range() Mike Rapoport
2024-04-22 2:55 ` Wei Yang [this message]
2024-04-24 13:15 ` Mike Rapoport
2024-04-25 1:38 ` Wei Yang
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=20240422025500.n5542xmrc3zy4qgb@master \
--to=richard.weiyang@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=rppt@kernel.org \
--cc=tjytimi@163.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox