[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] slightly consolidate code in free_domheap_pages()



On Tue, 2014-06-24 at 11:25 +0100, Jan Beulich wrote:
> >>> On 24.06.14 at 12:04, <Ian.Campbell@xxxxxxxxxxxxx> wrote:
> > On Fri, 2014-06-20 at 13:40 +0100, Jan Beulich wrote:
> > 
> >> +        if ( likely(d) && likely(d != dom_cow) )
> > 
> > OOI is this more or less efficient than a single likely around the
> > entire thing?
> 
> likely()/unlikely() around && or || expressions is never having the
> intended effect unless these expressions can be guaranteed to
> result in only a single branch instruction in the compiled code.
> That's because branch likelihood needs to be determined for each
> branch instruction individually (and e.g. likely(x && y) doesn't
> necessarily mean likely(x) && likely(y), i.e. it may only be the
> particular combination of the two that is likely).

Make sense, thanks.

> >> +        else
> >> +        {
> >> +            ASSERT(!d || !order);
> > 
> > Is this effectively replacing the ASSERT(order == 0) In the previous d
> > == dom_cow case?
> 
> Yes.
> 
> > If so, can d at this point ever be anything other than dom_cow or NULL?
> > I don't think so. Given that I think ASSERT(!(d == dom_cow && order !=
> > 0)) would more clearly capture the intent of the test (with the spelling
> > out of the conditions being more important than the de morganing of the
> > expression).
> 
> Indeed, d can only be NULL or dom_cow here (being in the else part
> of the if() you quoted at the top). So an alternative might indeed be
> ASSERT(d != dom_cow || !order), but that seems less desirable to
> me as it opens up ways to pass the ASSERT() with d != NULL should
> the if() condition ever get modified. I.e. I'd prefer the assertion to be
> as restrictive as possible, getting relaxed only when in fact necessary.

Since the original if involves d == dom_cow but nothing to do with order
it seemed that the check was somehow specific to dom_cow's relationship
to higher order allocations.

I suppose the question is what relationship would a non-NULL d have to
the order of the allocation. i.e. if the if were changed to also
consider dom_foo why would we expect now that dom_foo had any order
requirements?

Ian.


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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.