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

[Juergen Gross <jgross@suse.com>]

On 08/09/16 13:11, Wei Liu wrote:
> 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.

The first scheduling is done via unpausing the domain. Why not setting
the flag to true in that path?

Juergen

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