Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device

[Anthony Liguori <anthony@codemonkey.ws>]

On 02/25/2010 11:11 AM, Avi Kivity wrote:
> On 02/25/2010 05:06 PM, Paul Brook wrote:
>>>> Idle bottom halves (i.e. qemu_bh_schedule_idle) are just bugs 
>>>> waiting to
>>>> happen, and should never be used for anything.
>>> Idle bottom halves make considerable more sense than the normal bottom
>>> halves.
>>>
>>> The fact that rescheduling a bottom half within a bottom half 
>>> results in
>>> an infinite loop is absurd.  It is equally absurd that bottoms halves
>>> alter the select timeout.  The result of that is that if a bottom half
>>> schedules another bottom half, and that bottom half schedules the
>>> previous, you get a tight infinite loop.  Since bottom halves are used
>>> often times deep within functions, the result is very subtle infinite
>>> loops (that we've absolutely encountered in the past).
>> I disagree. The "select timeout" is a completely irrelevant 
>> implementation
>> detail. Anything that relies on it is just plain wrong. If you 
>> require a delay
>> then you should be using a timer. If scheduling a BH directly then 
>> you should
>> expect it to be processed without delay.
>
> I agree.  Further, once we fine-grain device threading, the iothread 
> essentially disappears and is replaced by device-specific threads.  
> There's no "idle" anymore.

That's a nice idea, but how is io dispatch handled?  Is everything 
synchronous or do we continue to program asynchronously?

It's very difficult to mix concepts.  I personally don't anticipate 
per-device threading but rather anticipate re-entrant device models.  I 
would expect all I/O to be dispatched within the I/O thread and the VCPU 
threads to be able to execute device models simultaneously with the I/O 
thread.

Regards,

Anthony Liguori