Re: [Xen-devel] patches pending acks (or naks)

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Dec 11, 2014 at 03:38:39PM +0000, Jan Beulich wrote:
> >>> On 11.12.14 at 16:18, <konrad.wilk@xxxxxxxxxx> wrote:
> > On December 11, 2014 6:39:07 AM EST, Jan Beulich <JBeulich@xxxxxxxx> wrote:
> >>Either
> >>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg00260.html 
> >>or (my preference)
> >>http://lists.xenproject.org/archives/html/xen-devel/2014-12/msg01054.html 
> >>
> > 
> > Daniel's patch fixes the case for EFI map or large CPU count (to a certain 
> > extent). Jan's patch only fixes it for large CPU count. The memmap can be 
> > huge on small CPU count machines.
> 
> The EFI memory map gets printed much later than when the ring
> buffer gets set up with "conring_size=" present.

Right..
> 
> > A proper fix would be to automatically adjust based on memmap and CPU but 
> > that could be too complex.
> 
> The problem isn't the complexity, but the chicken-and-egg problem
> as far as CPU count is concerned. The memory map size would be
> known early enough.

Let me explain my thought process:
 - There are existing knobs that can be used to change this (conring_size=X)
 - But we would like an awesome release where those knobs don't have to
   be used.
 - The patch you posted could be reworked to fully address memmap and CPU.
 - I don't know what your time constraints are for said patch and you
   might not have the energy to rework it.
 - I don't want to put pressure on you or Daniel on having to write new
   patches - especially as folks are going on vacation soon.

Hence as a fallback I believe that Daniel's patch should go in and
Jan's patch can go in too. However if Jan (or somebody else) wants to
rework the v2 (or a new one) to address the memmap issue then that
patch would go in - instead of Daniel's or v2 of Jan patch.

> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel