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

[Paul Brook <paul@codesourcery.com>]

> Very simply, without idle bottom halves, there's no way to implement
> polling with the main loop.  If we dropped idle bottom halves, we would
> have to add explicit polling back to the main loop.
> 
> How would you implement polling?

AFAICS any sort of polling is by definition time based so use a timer.
Forcing the user to explicitly decide how often to poll is a feature. If they 
don't know this then they probably shouldn't be using polling.

> > I don't see how this helps. A self-triggering event with a timeout of
> > "now" is still an infinite loop. Any delay is a bugs in the dispatch
> > loop. "idle" BHs are relying on this bug.
> 
> The main point is that BHs should not be implemented in the actual main
> loop and that "idle" BHs are really the only type of BHs that should
> exist as far as the main loop is concerned.  s/"idle" BHs/idle
> callbacks/g and I think we're at a more agreeable place.

Part of my difficulty is that I don't have a clear idea what "idle" means. It 
certainly isn't what qemu_bh_schedule_idle implements. 

The only vaguely sane definition I can come up with is once the main loop has 
run out of useful things to do and is about to suspend itself.  Typically no 
significant guest code will be executed between requesting the idle callback 
and the callback occurring. In an SMP host environment it may be possible for 
guest CPUs to trigger or observe intermediate events, but this can not be 
relied upon. Given this definition I'm unclear how useful this would be.

A BH is a deferred callback that is used to allow events to be processed. IMO 
the important feature is that it is a deferred until after the current event 
has been processed, so avoid a whole set of reentrancy problems.  Of course if 
you misuse them you can cause infinite loops, in the same way that misusing a 
regular callback will lead to infinite recursion.

I'm not sure that replacing BHs with zero interval timers actually gains us 
anything.  From a user(device) perspective I'd be more inclined to make timers 
trigger a BH when they expire, like the ptimer code.  Idle events can then be 
handled in exactly the same way: the user provides a BH which is triggered the 
next time the idle event occurs.

The exact source of a call to a BH routine from is an implementation detail. 
The important thing is that they will never be invoked from within or 
concurrent with any other device callback.

Paul