qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH 11/19] use a bottom half to run timers


From: Anthony Liguori
Subject: [Qemu-devel] Re: [PATCH 11/19] use a bottom half to run timers
Date: Tue, 05 Jan 2010 07:06:20 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

On 01/05/2010 06:48 AM, Paolo Bonzini wrote:
On 01/05/2010 12:59 AM, Anthony Liguori wrote:

When I think of a main loop, I think of something that provides the
following three services

1) fd based events
2) time based events
3) an idle callback

The problem we have is that bottom halves aren't quite idle callbacks.
They have some really weird properties about the guarantees of when
they're executed.  At any rate, you really cannot express a time based
event as an idle callback because you need to setup the select() timeout
based on the next deadline and then dispatch timer event based on
selects return.  idle functions have none of this ability.

I see bottom halves as a fourth service, providing the ability to synchronize stuff that needs to execute in a particular thread (guaranteeing thread-safety and especially signal-safety).

Thread and signal safety are slightly different. Scheduling an idle callback from a signal handler is a pretty reasonable thing to do.

Executing no a different thread is a whole different matter. Right now, we really use bottom halves to run something on the io thread and have a different mechanism that ran on a specific thread. Right now, we mix that between bottom halves and on_vcpu.

In some sense, the problem is that bottom halves conflate this service _and_ idle callbacks, and that is the weird property. Idle callbacks are used basically only for DMA, and real-world DMA does not have at all the semantics that qemu_bh_schedule_idle provides (which in turn is very tricky and not exactly what comments in qemu_bh_update_timeout promise).

I think before we can do any major surgery, we need to redo the way that legacy DMA is handled so that it doesn't require constant polling as it does now.

Regards,

Anthony Liguori




reply via email to

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