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

[Xen-devel] Re: Xen spinlock questions

>> 2) While on native not re-enabling interrupts in __raw_spin_lock_flags()
>> may be tolerable (but perhaps questionable), not doing so at least on
>> the slow path here seems suspicious.
>I wasn't sure about that.  Is it OK to enable interrupts in the middle 
>of a spinlock?  Can it be done unconditionally?

That used to be done in the pre-ticket lock implementation, but of course
conditional upon the original interrupt flag.

Later yesterday I noticed another issue: The code setting lock_spinners
isn't interruption safe - you'll need to return the old value from
spinning_lock() and restore it in unspinning_lock().

Also I'm considering doing it ticket-based nevertheless, as "mix(ing) up
next cpu selection" won't really help fairness in xen_spin_unlock_slow().
Apart from definitely needing the wakeup to happen for just the target
CPU (Keir, I'd want the necessary support in Xen done for that to work
regardless of performance measurements with the traditional locking,
as it's known that with ticket locks performance suffers from wrong-
order CPU kicking), one thing we'd be in even more need for here than
old-style spin locks had been would be a directed yield (sub-)hypercall.
Has that ever been considered to become a schedop?


Xen-devel mailing list



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