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

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

>>> 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).


Xen-devel mailing list



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