[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the
From: |
Alex Bennée |
Subject: |
Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree |
Date: |
Mon, 06 Nov 2017 16:30:57 +0000 |
User-agent: |
mu4e 1.0-alpha0; emacs 26.0.90 |
Paolo Bonzini <address@hidden> writes:
> On 06/11/2017 14:05, Alex Bennée wrote:
>>
>> Paolo Bonzini <address@hidden> writes:
>>
>>> On 03/11/2017 10:47, Alex Bennée wrote:
>>>> As deadlocks are easy to introduce a new rule is introduced that the
>>>> replay_mutex_lock is taken before any BQL locks. Conversely you cannot
>>>> release the replay_lock while the BQL is still held.
>>>
>>> I agree with the former, but the latter is unnecessary.
>>
>> I'm trying to think of occasions where this might cause us problems. The
>> BQL is a event level lock, generally held for HW event serialisation and
>> the replay_lock is synchronising batches of those events to the
>> advancement of "time".
>
> I would say that the BQL is "just" protecting data that has no other
> finer-grain lock.
>
> The replay_lock is (besides protecting record/replay status)
> synchronizing events so that threads advance in lockstep, but the BQL is
> also protecting things unrelated to recorded events. For those it makes
> sense to take the BQL without the replay lock. Replacing
> unlock_iothread/unlock_replay/lock_iothread with just unlock_replay is
> only an optimization.
OK, let's revise to:
Locking and thread synchronisation
----------------------------------
Previously the synchronisation of the main thread and the vCPU thread
was ensured by the holding of the BQL. However the trend has been to
reduce the time the BQL was held across the system including under TCG
system emulation. As it is important that batches of events are kept
in sequence (e.g. expiring timers and checkpoints in the main thread
while instruction checkpoints are written by the vCPU thread) we need
another lock to keep things in lock-step. This role is now handled by
the replay_mutex_lock. It used to be held only for each event being
written but now it is held for a whole execution period. This results
in a deterministic ping-pong between the two main threads.
As the BQL is now a finer grained lock than the replay_lock it is
almost certainly a bug taking the replay_mutex_lock while the BQL is
held. This is enforced by an assert. While the unlocks are usually in
the reverse order it is not necessary and therefor you can drop the
replay_lock while holding the BQL rather than doing any more
unlock/unlock/lock sequences.
>
> Paolo
>
>> How about:
>>
>> As deadlocks are easy to introduce a new rule is introduced that the
>> replay_mutex_lock is taken before any BQL locks. While you would
>> usually unlock in the reverse order this isn't strictly enforced. The
>> important thing is any work to record the state of a given hardware
>> transaction has been completed as once the BQL is released the
>> execution state may move on.
>>
--
Alex Bennée
- Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree, Paolo Bonzini, 2017/11/02
- Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree, Paolo Bonzini, 2017/11/02
- Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree, Pavel Dovgalyuk, 2017/11/03
- Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree, Alex Bennée, 2017/11/03
- Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree, Paolo Bonzini, 2017/11/03
- Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree, Alex Bennée, 2017/11/06
- Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree, Paolo Bonzini, 2017/11/06
- Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree,
Alex Bennée <=
- Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree, Paolo Bonzini, 2017/11/06
- Re: [Qemu-devel] [RFC PATCH 17/26] replay: push replay_mutex_lock up the call tree, Paolo Bonzini, 2017/11/03