[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation
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@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |