Re: [PATCH RFC v2 2/2] linux/vnuma: Enables NUMA for domu PV guest

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Wed, Sep 18, 2013 at 05:14:49PM +0200, Dario Faggioli wrote:
> On mar, 2013-09-17 at 04:34 -0400, Elena Ufimtseva wrote:
> > diff --git a/arch/x86/xen/setup.c b/arch/x86/xen/setup.c
> > index 8f3eea6..2f2d28e 100644
> > --- a/arch/x86/xen/setup.c
> > +++ b/arch/x86/xen/setup.c
> >
> >  #include <xen/xen.h>
> >  #include <xen/page.h>
> > @@ -583,6 +584,9 @@ void __init xen_arch_setup(void)
> >  	WARN_ON(xen_set_default_idle());
> >  	fiddle_vdso();
> >  #ifdef CONFIG_NUMA
> > -	numa_off = 1;
> > +	if (!xen_initial_domain() && xen_vnuma_support())
> > +		numa_off = 0;
> > +	else
> > +		numa_off = 1;
> >  #endif
> >  }
> I can't be positive about this, but I think that, if we go for David's
> suggestions of:
>  - testing for the hypercall being actually supported,
>  - calling dummy_numa_init() directly from within xen_numa_init (in 
>    case something go wrong), instead of going through all the 
>    alternatives from x86_numa_init()
> 
> then we can even get rid of this numa_off=0|1 all together (which is
> also something David was already suggesting, AFAICR).


You could do:

	if (xen_initial_domain()) && !xen_vnuma_support())
		numa_off = 1;

And just do that. The PV guest (the plain one) can then go on
and just do the dummy one.


> 
> It would be nice to know what the issue was at the time they had to
> introduce this, and whether we can get to do some testing on any of the
> boxes where it was exploding.

konrad@phenom:~/linux$ git annotate arch/x86/xen/setup.c|grep numa_off
8d54db795       (Konrad Rzeszutek Wilk  2012-08-17 10:22:37 -0400       601)    numa_off = 1;
konrad@phenom:~/linux$ git show 8d54db795
commit 8d54db795dfb1049d45dc34f0dddbc5347ec5642
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date:   Fri Aug 17 10:22:37 2012 -0400

    xen/boot: Disable NUMA for PV guests.
....
    this scanning is still enabled (K8 and Fam10h, not Bulldozer class)
..
    Pid: 0, comm: swapper Not tainted 3.3.6 #1 AMD Dinar/Dinar



> 
> I'll investigate more, in the meanwhile, does anyone had any clue?
> 
> Dario
> 
> -- 
> <<This happens because I choose it to happen!>> (Raistlin Majere)
> -----------------------------------------------------------------
> Dario Faggioli, Ph.D, http://about.me/dario.faggioli
> Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
> 



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