On 02/22/2010 09:32 AM, Avi Kivity wrote:
On 02/22/2010 05:29 PM, Anthony Liguori wrote:
On 02/22/2010 09:16 AM, Marcelo Tosatti wrote:
Are you concerned about spurious wakeups?
Yes. Also, qemu_notify_event() is an undirected notification (wakes
up all iothreads, and all devices), whereas ->handle_output() is
directed (wakes up exactly what is needed).
What's the underlying problem? A new input buffer has become
available, and we need to re-poll the incoming file descriptor? If
so, that's best done from ->handle_output() (either by waking the
iothread or calling read() itself and perhaps receiving -EAGAIN).
Yes. Sure, perhaps calling read() itself is appropriate, and i see
your point that>handle_output contains more context for a smarter
decision.
But one can argue thats an improvement on top of a dumb wakeup.
Spurious calls to qemu_notify_event() also make it difficult to tell
when it's actually necessary to call qemu_notify_event() vs. when
it's just something that doesn't hurt.
One improvement in this area would be to add a context parameter
(which eventually resolves to the underlying thread). Currently we'd
ignore it since we have just one iothread, but it would serve to
document what's being polled, and later direct the wakeup to the
correct thread.
Ends up looking a lot like a condition. It's not necessarily a bad
thing to model.
Regards,
Anthony Liguori
