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/23/2010 08:58 PM, Paul Brook wrote:
>> Bottom halves are run at the very end of the event loop which means that
>> they're guaranteed to be the last thing run.  idle bottom halves can be
>> rescheduled without causing an infinite loop and do not affect the
>> select timeout (which normal bottom halves do).
>>      
> 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).

A main loop should have only a few characteristics.  It should enable 
timeouts (based on select), it should enable fd event dispatch, and it 
should allow for idle functions to be registered.  There should be no 
guarantees on when idle functions are executed other than they'll 
eventually be executed.

The way we use "bottom halves" today should be implemented in terms of a 
relative timeout of 0 or an absolute timeout of now.  The fact that we 
can't do that in our main loop is due to the very strange dependencies 
deep within various devices on io dispatch ordering.  I would love to 
eliminate this but I've not been able to spend any time on this recently.

Regards,

Anthony Liguori

> Paul
>