BTW, I just meant for time rendezvous code, not for what you're
adding to spinlock which seems safer to avoid similar dead lock
when real rendezvous usage is introduced in future.
Thanks,
Kevin
>From: Tian, Kevin
>Sent: Tuesday, October 21, 2008 8:50 PM
>
>>From: Keir Fraser [mailto:keir.fraser@xxxxxxxxxxxxx]
>>Sent: Tuesday, October 21, 2008 8:37 PM
>>On 21/10/08 13:29, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>>
>>>> Actually this new partitioning of locks into two
>>equivalence classes is
>>>> begging for some run-time checking in debug builds. I'll sort
>>>> out a patch
>>>> for that.
>>>
>>> Did you flush out the patch into xen bits? I guess there may
>>> be other instances breaking that guideline. Just curious whether
>>> Linux side already recognized similar constraints. It's possibly
>>> not. Then another angle is, instead of pushing constraint on
>>> spinlock usage, could we instead change timer rendezvous
>>> style? Use softirq instead of call function should release the
>>> constraints like stop_machine. :-)
>>
>>I'm flushing out fixes for this class of race before I check
>>in the debug
>>code. I don't think it's an unreasonable new constraint, it
>>just hasn't been
>>enforced before and so various Xen code breaks. I should get
>>the patches
>>flushed out later today.
>
>I'm a bit curious why call funtion ipi is required here, or why
>rendezvous is required here. All the rendezvous stuff in current
>ipi function is just:
>a) cpu0 waits for all other cpus entering rendezvous loop, and
>then update master_stime
>b) other cpus enter loop and wait for cpu0 to update master_stime
>
>Then each cpu continues with rest stuff independently. In this
>case, it seems enough to just ensure master_stime updated
>before sending softirq, and thus ipi is actually not required.
>Do I miss anything? :-)
>
>Thanks,
>Kevin
>
>_______________________________________________
>Xen-devel mailing list
>Xen-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-devel
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home