qemu-stable
[Top][All Lists]
Advanced

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

Re: [Qemu-stable] [Qemu-devel] [PATCH] acpi: SRAT: do not create reserve


From: Igor Mammedov
Subject: Re: [Qemu-stable] [Qemu-devel] [PATCH] acpi: SRAT: do not create reserved gap entries
Date: Mon, 13 Aug 2018 09:07:13 +0200

On Fri, 10 Aug 2018 15:28:35 -0300
Eduardo Habkost <address@hidden> wrote:

> On Fri, Aug 10, 2018 at 06:01:06PM +0200, Igor Mammedov wrote:
> > On Fri, 10 Aug 2018 16:06:57 +0200
> > Igor Mammedov <address@hidden> wrote:
> >   
> > > Commit 848a1cc1e8b04 while introducing SRAT entries for DIMM and NVDIMM
> > > also introduced fake entries for gaps between memory devices, assuming
> > > that we need all possible range covered with SRAT entries.
> > > And it did it wrong since gap would overlap with preceeding entry.
> > > Reproduced with following CLI:
> > > 
> > >  -m 1G,slots=4,maxmem=8 \
> > >  -object memory-backend-ram,size=1G,id=m0 \
> > >  -device pc-dimm,memdev=m0,addr=0x101000000 \
> > >  -object memory-backend-ram,size=1G,id=m1 \
> > >  -device pc-dimm,memdev=m1
> > > 
> > > However recent development (10efd7e108) showed that gap entries might
> > > be not need. And indeed testing with WS2008DC-WS2016DC guests range
> > > shows that memory hotplug works just fine without gap entries.
> > > 
> > > So rather than fixing gap entry borders, just drop them altogether
> > > and simplify code around it.
> > > 
> > > Spotted-by: Laszlo Ersek <address@hidden>
> > > Signed-off-by: Igor Mammedov <address@hidden>
> > > ---
> > > There is no need to update reference blobs since gaps beween dimms
> > > aren't generated by any exsting test case.
> > > 
> > > Considering issue is not visible by default lets just merge it into 3.1
> > > and stable 3.0.1  
> > Pls ignore it for now I'll need to do more extensive testing with old 
> > kernels,
> > we might need these holes for old kernels or even new ones.
> > /me goes to read kernel code
> > 
> > /per spec possible to hotplug range could be in SRAT,
> >  even though I don't like it bu we might end up with static
> >  partitioning of hotplug area between nodes like on bare metal
> >  to avoid chasing after unknown requirements from windows /  
> 
> Does that mean we might want to pair DIMM slots with NUMA nodes
> in advance?  Do you have a suggestion on how the command-line
> would look like, in this case?
> 
> Maybe "-numa mem-slot,slot=X,node=Y"?
it's either, to make it per slot (it implies fixed maximum size per slot)
or a bit more flexible maxmem per node, might be something like:
  -numa memory,node=X,maxmem=Y






reply via email to

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