[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
Wei Liu writes ("Re: [PATCH v3 1/1] xen: move TLB-flush filtering out into populate_physmap during vm creation"): > 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: > > > > + 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. Are we sure we ought to be discussing this in terms of optimisation ? I doubt it makes any significant difference either way. But there is a difference in clarity. I would not normally expect to see this: bool x; ... if (!x) x = 1; If I saw that I would wonder if the programmer was confused, or whether I was missing something. Looking at it without the benefit of the definition of x, it looks more like x might be a non-boolean type. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx https://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |