Re: [patch uq/master 1/2] virtio-pci: wake up iothread on VIRTIO_PCI_QUEUE_NOTIFY

[Anthony Liguori <anthony@codemonkey.ws>]

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