All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rebecca Mckeever <remckee0@gmail.com>
To: David Hildenbrand <david@redhat.com>
Cc: Mike Rapoport <rppt@kernel.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/4] memblock tests: add simulation of physical memory with multiple NUMA nodes
Date: Tue, 6 Sep 2022 18:43:06 -0500	[thread overview]
Message-ID: <20220906234306.GA4053@sophie> (raw)
In-Reply-To: <d57009d3-fd40-5061-31ae-203dff1e0ef7@redhat.com>

On Tue, Sep 06, 2022 at 03:17:46PM +0200, David Hildenbrand wrote:
> On 04.09.22 06:21, Rebecca Mckeever wrote:
> > Add function setup_numa_memblock() for setting up a memory layout with
> > multiple NUMA nodes in a previously allocated dummy physical memory.
> > This function can be used in place of setup_memblock() in tests that need
> > to simulate a NUMA system.
> > 
> > setup_numa_memblock():
> > - allows for setting up a memory layout by specifying the fraction of
> >    MEM_SIZE in each node
> > 
> > Set CONFIG_NODES_SHIFT to 4 when building with NUMA=1 to allow for up to
> > 16 NUMA nodes.
> > 
> > Signed-off-by: Rebecca Mckeever <remckee0@gmail.com>
> > ---
> >   .../testing/memblock/scripts/Makefile.include |  2 +-
> >   tools/testing/memblock/tests/common.c         | 29 +++++++++++++++++++
> >   tools/testing/memblock/tests/common.h         |  4 ++-
> >   3 files changed, 33 insertions(+), 2 deletions(-)
> > 
> > diff --git a/tools/testing/memblock/scripts/Makefile.include b/tools/testing/memblock/scripts/Makefile.include
> > index aa6d82d56a23..998281723590 100644
> > --- a/tools/testing/memblock/scripts/Makefile.include
> > +++ b/tools/testing/memblock/scripts/Makefile.include
> > @@ -3,7 +3,7 @@
> >   # Simulate CONFIG_NUMA=y
> >   ifeq ($(NUMA), 1)
> > -	CFLAGS += -D CONFIG_NUMA
> > +	CFLAGS += -D CONFIG_NUMA -D CONFIG_NODES_SHIFT=4
> >   endif
> >   # Use 32 bit physical addresses.
> > diff --git a/tools/testing/memblock/tests/common.c b/tools/testing/memblock/tests/common.c
> > index eec6901081af..b6110df21b2a 100644
> > --- a/tools/testing/memblock/tests/common.c
> > +++ b/tools/testing/memblock/tests/common.c
> > @@ -72,6 +72,35 @@ void setup_memblock(void)
> >   	fill_memblock();
> >   }
> > +/**
> > + * setup_numa_memblock:
> > + * Set up a memory layout with multiple NUMA nodes in a previously allocated
> > + * dummy physical memory.
> > + * @nodes: an array containing the denominators of the fractions of MEM_SIZE
> > + *         contained in each node (e.g., if nodes[0] = SZ_8, node 0 will
> > + *         contain 1/8th of MEM_SIZE)
> > + *
> > + * The nids will be set to 0 through NUMA_NODES - 1.
> > + */
> > +void setup_numa_memblock(const phys_addr_t nodes[])
> > +{
> > +	phys_addr_t base;
> > +	int flags;
> > +
> > +	reset_memblock_regions();
> > +	base = (phys_addr_t)memory_block.base;
> > +	flags = (movable_node_is_enabled()) ? MEMBLOCK_NONE : MEMBLOCK_HOTPLUG;
> > +
> > +	for (int i = 0; i < NUMA_NODES; i++) {
> > +		assert(nodes[i] <= MEM_SIZE && nodes[i] > 0);
> 
> I think it would be even easier to get if this would just be a fraction.
> E.g., instead of "1/8 * MEM_SIZE" just "1/8". All values have to add up to
> 1.
> 
> ... but then we'd have to mess with floats eventually, so I guess this makes
> it easier to handle these fractions.
> 
> 
> We could use "int" and simply specify the fraction in percent, like
> 
> nodes[0] = 50;
> nodes[1] = 25;
> nodes[2] = 25;
> 
> and everything has to add up to 100.
> 
This would still be a float for 1/8th (12.5) and 1/16th (6.25). What if
it was the "percent" of 256 (i.e., 0x100)?
> 
> > +		phys_addr_t size = MEM_SIZE / nodes[i];
> 
> 
> Hmmm, assuming a single node with "MEM_SIZE", we would get size=1.
> 
For a single node of MEM_SIZE, nodes[0] would be 1.

> Shouldn't this be "size = nodes[i]"
> 
> ?
No, not with the current implementation. The nodes array stores the
denominator of the fraction that will be multiplied by MEM_SIZE to
determine the size of that node (the numerator is always 1). So if the
size of the node should be 1/8 * MEM_SIZE, the nodes array just stores
the 8. I think the name of the array is misleading. Do you have any
suggestions for a better name?
> 
> -- 
> Thanks,
> 
> David / dhildenb
> 
Thanks,
Rebecca


  reply	other threads:[~2022-09-06 23:43 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-04  4:21 [PATCH v4 0/4] memblock tests: add NUMA tests for memblock_alloc_try_nid* Rebecca Mckeever
2022-09-04  4:21 ` [PATCH v4 1/4] memblock tests: add simulation of physical memory with multiple NUMA nodes Rebecca Mckeever
2022-09-06 13:17   ` David Hildenbrand
2022-09-06 23:43     ` Rebecca Mckeever [this message]
2022-09-07  8:44       ` David Hildenbrand
2022-09-07 23:52         ` Rebecca Mckeever
2022-09-04  4:21 ` [PATCH v4 2/4] memblock tests: add top-down NUMA tests for memblock_alloc_try_nid* Rebecca Mckeever
2022-09-08 12:23   ` David Hildenbrand
2022-09-04  4:21 ` [PATCH v4 3/4] memblock tests: add bottom-up " Rebecca Mckeever
2022-09-08 12:26   ` David Hildenbrand
2022-09-04  4:21 ` [PATCH v4 4/4] memblock tests: add generic " Rebecca Mckeever
2022-09-08 12:26   ` David Hildenbrand

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=20220906234306.GA4053@sophie \
    --to=remckee0@gmail.com \
    --cc=david@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --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.