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

[Xen-devel] Re: [PATCH RFC 02/12] x86/ticketlock: convert spin loop to C



 On 08/06/2010 02:09 PM, H. Peter Anvin wrote:
On 08/06/2010 01:33 PM, Jeremy Fitzhardinge wrote:
On 08/06/2010 01:17 PM, H. Peter Anvin wrote:
On 08/06/2010 07:53 AM, Jeremy Fitzhardinge wrote:
On 08/06/2010 05:43 AM, Jan Beulich wrote:
You certainly mean "the compiler currently treats this as being:" - I
don't think there's a guarantee it'll always be doing so.

for (;;) {
if (inc.tickets.head == inc.tickets.tail)
goto out;
...
}
out: barrier();
}

(Which would probably be a reasonable way to clarify the code.)
I therefore think it needs to be written this way.

Agreed.


A call/return to an actual out-of-line function is a barrier (and will
always be a barrier, as it is the fundamental ABI sequence points),
but to an inline function it is not.

Yes. So the goto explicitly puts the barrier into the control flow which
should stop the compiler from doing anything unexpected.


In this particular case, though, I would somewhat expect the more conventional:

while (inc.tickets.head != inc.tickets.tail) {
    cpu_relax();
    inc.tickets.head = ACCESS_ONCE(lock->tickets_head);
}

Yes, that makes sense for the plain spinlock version. But the full code, including the pv-ticketlock spin timeout, ends up being:

static __always_inline void arch_spin_lock(struct arch_spinlock *lock)
{
        register struct __raw_tickets inc;

        inc = __ticket_spin_claim(lock);

        for (;;) {
                unsigned count = SPIN_THRESHOLD;

                do {
                        if (inc.head == inc.tail)
                                goto out;
                        cpu_relax();
                        inc.head = ACCESS_ONCE(lock->tickets.head);
                } while (--count);
                __ticket_lock_spinning(lock, inc.tail);
        }
out:    barrier();              /* make sure nothing creeps before the lock is 
taken */
}

So the goto form is closer to the final form. If it weren't for this, I'd also prefer the while() form.

(If you config PARAVIRT_SPINLOCKS=n, then __ticket_lock_spinning() becomes an empty inline, which causes gcc to collapse the whole thing into a simple infinite loop (ie, it eliminates "count" and the inner loop).)


    J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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