[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH 0/3] qemu-timer: make QEMUTimer functions thread
From: |
Paolo Bonzini |
Subject: |
Re: [Qemu-devel] [PATCH 0/3] qemu-timer: make QEMUTimer functions thread-safe |
Date: |
Mon, 15 Jul 2013 15:38:15 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 |
Il 15/07/2013 14:57, Jan Kiszka ha scritto:
> On 2013-07-15 14:45, Paolo Bonzini wrote:
>> Il 05/07/2013 19:51, Jan Kiszka ha scritto:
>>> On 2013-07-05 14:39, Stefan Hajnoczi wrote:
>>>> This series makes the following functions thread-safe:
>>>>
>>>> qemu_mod_timer_ns()
>>>> qemu_mod_timer()
>>>> qemu_del_timer()
>>>> qemu_timer_pending()
>>>>
>>>> The following were already thread-safe:
>>>>
>>>> qemu_free_timer()
>>>> qemu_new_timer()
>>>> qemu_timer_expired()
>>>>
>>>> Now it is possible to use QEMUTimer outside the QEMU global mutex. Timer
>>>> callbacks are still invoked from the main loop. If a thread wishes to run
>>>> timer callbacks it must use a thread-safe QEMUBH (which Ping Fan Liu is
>>>> working
>>>> on).
>>>
>>> What do you mean with this? We need main-loop independent timers for any
>>> task that depends on timely alarm delivery. Do your patches keep this in
>>> mind as well?
>>
>> These are orthogonal issues. Stefan's usecase does not need timely
>> delivery.
>
> Not necessarily. Timely delivery is likely the harder requirement that
> also fulfills the need to move timer setup/manipulation outside of BQL.
> I didn't have time to look into details yet, but there is a risk that
> this rework will not help to achieve RT qualities
Not a risk, a certainty. :)
> but rather needs another, non-orthogonal rework.
If you consider the "timers as a library" approach from your
presentation at last year's KVM Forum, this series does nothing to help
that goal.
But it also does nothing to hinder it (all it does is add a mutex,
basically), which is why I said it is orthogonal.
Paolo