Re: Xen PVM: Strange lockups when running PostgreSQL load

[Stefan Bader <stefan.bader@canonical.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1347 bytes --]

On 18.10.2012 12:47, Jan Beulich wrote:
>>>> On 18.10.12 at 12:20, Stefan Bader <stefan.bader@canonical.com> wrote:
>> On 18.10.2012 09:48, Ian Campbell wrote:
>>> spinning_lock() returns the old lock which the caller is expected to
>>> remember and replace via unspinning_lock() -- it effectively implements
>>> a stack of locks which are being waited on. xen_spin_lock_slow (the only
>>> caller0 appears to do this correctly from a brief inspection.
>>
>> Yes, just *when* can there be a stack of locks (spinlocks). The poll_irq
>> hypercall seems to be an active (in the sense of not preemting to another 
>> task)
>> process. How could there be a situation that another lock (on the same cpu 
>> is tried to be taken).
> 
> Obviously when this is an acquire not disabling interrupts, and
> an interrupt comes in while in the poll hypercall (or about to go
> there, or just having come back from one).
> 
> Jan
> 
Obviously. ;) Ok, so my thinking there was ok and its one level deep max. At
some point staring at things I start question my sanity.
A wild thinking would be whether in that case the interrupted spinlock may miss
a wakeup forever when the unlocker only can check for the toplevel. Hm, but that
should be easy to rule out by just adding an error to spin_unlock_slow when it
fails to find anything...



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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