Re: [Xen-devel] [PATCHv3 0/4] Use ticket locks for spinlocks

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 30.04.15 at 17:44, <david.vrabel@xxxxxxxxxx> wrote:
> On 23/04/15 13:42, David Vrabel wrote:
>> On 21/04/15 11:22, Jan Beulich wrote:
>>>>>> On 21.04.15 at 12:11, <david.vrabel@xxxxxxxxxx> wrote:
>>>> We have analysed the affect of this series on interrupt latency (by
>>>> measuring the duration of irq disable/enable regions) and there is no
>>>> signficant impact.
>>>>
>>>> http://xenbits.xen.org/people/dvrabel/bar2_comp.png 
>>>
>>> Thanks for doing this!
>>>
>>>> Interestingly, the biggest offenders for long critical sections are
>>>> bare irq disable/enable regions, and some of these are really bad (10s
>>>> of ms)!
>>>>
>>>> http://xenbits.xen.org/people/dvrabel/bar_normal_busy.png 
>>>
>>> Despite both pictures saying micro-seconds at the respective
>>> axis (and hence the problem not being _as bad_)
>> 
>> This particular graph doesn't show it very well but there are small
>> blips around 4, 10, and 31 ms.
> 
> This first set of analysis incorrect included some bogus data.
> 
> 1. The mwait idle driver has interrupts masked for the mwait instruction
> (with the wake-on-interrupt bit enabled), thus the very long times were
> measuring idle time.
> 
> 2. do_IRQ() calls spin_unlock_irq() without a corresponding
> spin_lock_irq() thus the values for this lock were incorrect.
> 
> Here's an updated graph (Thanks to Jennifer).
> 
> http://xenbits.xen.org/people/dvrabel/ticket-locks/busy_byte.png 
> 
> The durations are all more reasonable now.

Thanks for doing this! I think this makes clear that there's no
immediate need for any further investigation then (a couple of
microsecond IRQ-disabled sections don't seem to be a problem
for other than true real-time uses).

Jan


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