qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]