Re: [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation

[Wei Liu <wei.liu2@citrix.com>]

On Thu, Sep 08, 2016 at 01:01:40PM +0200, Dario Faggioli wrote:
> On Thu, 2016-09-08 at 11:50 +0100, Wei Liu wrote:
> > On Thu, Sep 08, 2016 at 01:30:03PM +0800, Dongli Zhang wrote:
> > > 
> > > diff --git a/xen/common/schedule.c b/xen/common/schedule.c
> > > index 32a300f..593541a 100644
> > > --- a/xen/common/schedule.c
> > > +++ b/xen/common/schedule.c
> > > @@ -1376,6 +1376,11 @@ static void schedule(void)
> > >  
> > >      next = next_slice.task;
> > >  
> > > +    /* Set already_scheduled to 1 when this domain gets scheduled
> > > for the
> > > +     * first time */
> > > +    if ( next->domain->already_scheduled == 0 )
> > > +        next->domain->already_scheduled = 1;
> > > +
> > Can be simplified by omitting the "if" altogether.  
> >
> Are you sure? I mean looking at the cases when the flag is already true
> (which means, during the life of a domain, basically **always** except
> a handful of instances after creation), what costs less, a check that
> is always false, or a write that is always updating a value with its
> current value?

Omitting the check certain results in less instructions. And it would
probably eliminate misses in instruction cache and branch prediction
logic in the processor.

In the grand scheme of things, this is a rather minor optimisation, so I
wouldn't argue strongly for this.

Wei.

> 
> And I'm not being ironic or anything, I honestly am not sure and this
> is a genuine question.
> 
> > And use "true" here.
> > 
> Yeah, or just:
> 
>  if ( unlikely(!next->domain->already_scheduled) )
>      ...
> 
> > Wei.
> -- 
> <<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
https://lists.xen.org/xen-devel