qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH v1 3/4] numa: Store boot memory address rang


From: Bharata B Rao
Subject: Re: [Qemu-devel] [RFC PATCH v1 3/4] numa: Store boot memory address range in node_info
Date: Wed, 17 Jun 2015 08:47:21 +0530
User-agent: Mutt/1.5.23 (2014-03-12)

On Mon, Jun 15, 2015 at 01:31:20PM -0300, Eduardo Habkost wrote:
> On Fri, Jun 12, 2015 at 02:30:27PM +0530, Bharata B Rao wrote:
> > Store memory address range information of boot memory  in address
> > range list of numa_info.
> > 
> > This helps to have a common NUMA node lookup by address function that
> > works for both boot time memory and hotplugged memory.
> > 
> > Signed-off-by: Bharata B Rao <address@hidden>
> > ---
> >  numa.c | 22 ++++++++++++++++++++++
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/numa.c b/numa.c
> > index 27ca743..d67b1fb 100644
> > --- a/numa.c
> > +++ b/numa.c
> > @@ -75,6 +75,26 @@ void numa_unset_mem_node_id(ram_addr_t addr, uint64_t 
> > size, uint32_t node)
> >      }
> >  }
> >  
> > +static void numa_set_mem_ranges(void)
> > +{
> > +    int i;
> > +    ram_addr_t mem_start, mem_end_prev;
> > +
> > +    /*
> > +     * Deduce start address of each node and use it to store
> > +     * the address range info in numa_info address range list
> > +     */
> > +    for (i = 0; i < nb_numa_nodes; i++) {
> > +        if (i) {
> > +            mem_start = mem_end_prev;
> > +        } else {
> > +            mem_start = 0;
> > +        }
> 
> You could simply initialize mem_end_prev=0 before entering the loop,
> instead.
> 
> Actually, you don't even need the mem_end_prev variable:
> 
>     int i;
>     ram_addr_t mem_start = 0;
> 
>     for (i = 0; i < nb_numa_nodes; i++) {
>         numa_set_mem_node_id(mem_start, numa_info[i].node_mem, i);
>         mem_start = mem_start + numa_info[i].node_mem;
>     }

Ok will change to this.

> 
> I was going to suggest moving this to
> memory_region_allocate_system_memory() instead (that already has a loop
> calculating the start address for each NUMA node), but the problem is
> that allocate_system_memory_nonnuma() may be called even if using NUMA
> if no memdevs are used. So this can be done later, after refactoring
> memory_region_allocate_system_memory() to have a single memory
> allocation code path.

If there are no more comments to be addressed in this series, I shall spin
the next version.

Regards,
Bharata.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]