All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Huang, Shaoqin" <shaoqin.huang@intel.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: Karolina Drobnik <karolinadrobnik@gmail.com>,
	David Hildenbrand <david@redhat.com>,
	Rebecca Mckeever <remckee0@gmail.com>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/3] memblock test: Add test to memblock_add() 129th region
Date: Thu, 1 Sep 2022 16:35:04 +0800	[thread overview]
Message-ID: <2d75b9c4-e126-0cc2-dca5-64c6ae9666de@intel.com> (raw)
In-Reply-To: <YxBnG4xYh/eIJ/ZT@kernel.org>



On 9/1/2022 4:02 PM, Mike Rapoport wrote:
> On Tue, Aug 30, 2022 at 09:49:17AM +0800, shaoqin.huang@intel.com wrote:
>> From: Shaoqin Huang <shaoqin.huang@intel.com>
>>
>> Add 129th region into the memblock, and this will trigger the
>> memblock_double_array() function, this needs valid memory regions. So
>> using dummy_physical_memory_init() to allocate a valid memory region, and
>> fake the other memory region, so it make sure the memblock_double_array()
>> will always choose the valid memory region that is allocated by the
>> dummy_physical_memory_init(). So memblock_double_array() must success.
>>
>> Another thing should be done is to restore the memory.regions after
>> memblock_double_array(), due to now the memory.regions is pointing to a
>> memory region allocated by dummy_physical_memory_init(). And it will
>> affect the subsequent tests if we don't restore the memory region. So
>> simply record the origin region, and restore it after the test.
>>
>> Signed-off-by: Shaoqin Huang <shaoqin.huang@intel.com>
>> ---
>>   tools/testing/memblock/tests/basic_api.c | 82 ++++++++++++++++++++++++
>>   tools/testing/memblock/tests/common.c    |  7 +-
>>   tools/testing/memblock/tests/common.h    |  3 +
>>   3 files changed, 90 insertions(+), 2 deletions(-)
>>
>> diff --git a/tools/testing/memblock/tests/basic_api.c b/tools/testing/memblock/tests/basic_api.c
>> index 66f46f261e66..c8e201156cdc 100644
>> --- a/tools/testing/memblock/tests/basic_api.c
>> +++ b/tools/testing/memblock/tests/basic_api.c
>> @@ -326,6 +326,87 @@ static int memblock_add_twice_check(void)
>>   	return 0;
>>   }
>>   
>> +/*
>> + * A test that tries to add the 129th memory block.
>> + * Expect to trigger memblock_double_array() to double the
>> + * memblock.memory.max, find a new valid memory as
>> + * memory.regions.
>> + */
>> +static int memblock_add_many_check(void)
>> +{
>> +	int i;
>> +	void *orig_region;
>> +	struct region r = {
>> +		.base = SZ_16K,
>> +		.size = MEM_SIZE,
>> +	};
>> +	phys_addr_t memory_base = SZ_128K;
>> +
>> +	PREFIX_PUSH();
>> +
>> +	reset_memblock_regions();
>> +	memblock_allow_resize();
>> +
>> +	/*
>> +	 * Add one valid memory region, this will be choosed to be the memory
>> +	 * that new memory.regions occupied.
>> +	 */
>> +	dummy_physical_memory_init();
>> +	memblock_add((phys_addr_t)get_memory_block_base(), MEM_SIZE);
>> +
>> +	ASSERT_EQ(memblock.memory.cnt, 1);
>> +	ASSERT_EQ(memblock.memory.total_size, MEM_SIZE);
>> +
>> +	for (i = 1; i < INIT_MEMBLOCK_REGIONS; i++) {
>> +		/* Add some fakes memory region to fulfill the memblock. */
>> +		memblock_add(memory_base, MEM_SIZE);
> 
> I would rather prefer to memblock_add() ranges from the simulated memory
> created in dummy_physical_memory_init(). 16K will be probably too small,
> but I don't see problem with increasing MEM_SIZE.
> 

Yes. If we memblock_add() the memory both allocated from 
dummy_physical_memory_init(), It's no need to fake these memory regions. 
And with all valid memory region, it will always choose a valid memory 
region and double the array.

And now with calculation, 16K is enough. The doubled array will only use 
8KB, so it will success.

>> +
>> +		ASSERT_EQ(memblock.memory.cnt, i + 1);
>> +		ASSERT_EQ(memblock.memory.total_size, (i + 1) * MEM_SIZE);
>> +
>> +		/* Keep the gap so these memory region will not be merged. */
>> +		memory_base += MEM_SIZE * 2;
>> +	}
>> +
>> +	orig_region = memblock.memory.regions;
>> +
>> +	/* This adds the 129 memory_region, and makes it double array. */
>> +	memblock_add((phys_addr_t)memory_base, MEM_SIZE);
> 
> memory_base is already phys_addr_t, isn't it?
> 

Thanks for notice. Will delete it.

>> +
>> +	ASSERT_EQ(memblock.memory.cnt, INIT_MEMBLOCK_REGIONS + 1);
>> +	ASSERT_EQ(memblock.memory.total_size, (INIT_MEMBLOCK_REGIONS + 1) * MEM_SIZE);
>> +	ASSERT_EQ(memblock.memory.max, INIT_MEMBLOCK_REGIONS * 2);
>> +
>> +	ASSERT_EQ(memblock.reserved.cnt, 1);
>> +	/* This is the size used by new memory.regions. Check it. */
>> +	ASSERT_EQ(memblock.reserved.total_size, PAGE_ALIGN(INIT_MEMBLOCK_REGIONS * 2 *
>> +						sizeof(struct memblock_region)));
>> +
> 
> Can you please elaborate what does the following sequence test?
> 

Before this line, all checks is to make sure the double_array have 
successfully make the size doubled and reserved a new region as the new 
memory.regions.

Below I try to add a memory region which has a small base, so it will be 
added to the first region, if it succeed. We can prove the doubled 
memory.regions has a valid memory.

I will add the commends in the next version.

>> +	/* The base is very small, so it should be insert to the first region. */
>> +	memblock_add(r.base, r.size);
>> +	ASSERT_EQ(memblock.memory.regions[0].base, r.base);
>> +	ASSERT_EQ(memblock.memory.regions[0].size, r.size);
>> +
>> +	ASSERT_EQ(memblock.memory.cnt, INIT_MEMBLOCK_REGIONS + 2);
>> +	ASSERT_EQ(memblock.memory.total_size, (INIT_MEMBLOCK_REGIONS + 2) * MEM_SIZE);
>> +	ASSERT_EQ(memblock.memory.max, INIT_MEMBLOCK_REGIONS * 2);
>> +
>> +	dummy_physical_memory_cleanup();
>> +
>> +	/*
>> +	 * The current memory.regions is occupying a range of memory that
>> +	 * allocated from dummy_physical_memory_init(). After free the memory,
>> +	 * we must not use it. So restore the origin memory region to make sure
>> +	 * the tests can run as normal and not affected by the double array.
>> +	 */
>> +	memblock.memory.regions = orig_region;
>> +	memblock.memory.cnt = INIT_MEMBLOCK_REGIONS;
>> +
>> +	test_pass_pop();
>> +
>> +	return 0;
>> +}
>> +
>>   static int memblock_add_checks(void)
>>   {
>>   	prefix_reset();
>> @@ -339,6 +420,7 @@ static int memblock_add_checks(void)
>>   	memblock_add_overlap_bottom_check();
>>   	memblock_add_within_check();
>>   	memblock_add_twice_check();
>> +	memblock_add_many_check();
>>   
>>   	prefix_pop();
>>   
>> diff --git a/tools/testing/memblock/tests/common.c b/tools/testing/memblock/tests/common.c
>> index 76a8ad818f3a..96fabd96ff31 100644
>> --- a/tools/testing/memblock/tests/common.c
>> +++ b/tools/testing/memblock/tests/common.c
>> @@ -5,8 +5,6 @@
>>   #include <linux/memory_hotplug.h>
>>   #include <linux/build_bug.h>
>>   
>> -#define INIT_MEMBLOCK_REGIONS			128
>> -#define INIT_MEMBLOCK_RESERVED_REGIONS		INIT_MEMBLOCK_REGIONS
>>   #define PREFIXES_MAX				15
>>   #define DELIM					": "
>>   
>> @@ -77,6 +75,11 @@ void dummy_physical_memory_cleanup(void)
>>   	free(memory_block.base);
>>   }
>>   
>> +void *get_memory_block_base(void)
>> +{
>> +	return memory_block.base;
>> +}
>> +
>>   static void usage(const char *prog)
>>   {
>>   	BUILD_BUG_ON(ARRAY_SIZE(help_opts) != ARRAY_SIZE(long_opts) - 1);
>> diff --git a/tools/testing/memblock/tests/common.h b/tools/testing/memblock/tests/common.h
>> index d396e5423a8e..d56af621c543 100644
>> --- a/tools/testing/memblock/tests/common.h
>> +++ b/tools/testing/memblock/tests/common.h
>> @@ -11,6 +11,8 @@
>>   #include <../selftests/kselftest.h>
>>   
>>   #define MEM_SIZE SZ_16K
>> +#define INIT_MEMBLOCK_REGIONS			128
>> +#define INIT_MEMBLOCK_RESERVED_REGIONS		INIT_MEMBLOCK_REGIONS
>>   
>>   /**
>>    * ASSERT_EQ():
>> @@ -73,6 +75,7 @@ void reset_memblock_attributes(void);
>>   void setup_memblock(void);
>>   void dummy_physical_memory_init(void);
>>   void dummy_physical_memory_cleanup(void);
>> +void *get_memory_block_base(void);
> 
> Let's make it
> 
> phys_addr_t dummy_physical_memory_base(void);
> 

Got it.

>>   void parse_args(int argc, char **argv);
>>   
>>   void test_fail(void);
>> -- 
>> 2.34.1
>>
>>
> 


  reply	other threads:[~2022-09-01  8:35 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30  1:49 [PATCH 0/3] Add tests trying to memblock_add() or memblock_reserve() 129th region shaoqin.huang
2022-08-30  1:49 ` [PATCH 1/3] memblock test: Add test to memblock_add() " shaoqin.huang
2022-09-01  8:02   ` Mike Rapoport
2022-09-01  8:35     ` Huang, Shaoqin [this message]
2022-08-30  1:49 ` [PATCH 2/3] memblock test: Add test to memblock_reserve() " shaoqin.huang
2022-09-01  8:08   ` Mike Rapoport
2022-09-01  8:43     ` Huang, Shaoqin
2022-08-30  1:49 ` [PATCH 3/3] memblock test: Update TODO list shaoqin.huang
  -- strict thread matches above, loose matches on Subject: below --
2022-08-22  2:33 [PATCH 0/3] Add tests trying to memblock_add() or memblock_reserve() 129th region shaoqin.huang
2022-08-22  2:33 ` [PATCH 1/3] memblock test: Add test to memblock_add() " shaoqin.huang

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=2d75b9c4-e126-0cc2-dca5-64c6ae9666de@intel.com \
    --to=shaoqin.huang@intel.com \
    --cc=david@redhat.com \
    --cc=karolinadrobnik@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=remckee0@gmail.com \
    --cc=rppt@kernel.org \
    /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.