[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows gu

From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device
Date: Wed, 24 Feb 2010 08:59:31 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0

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.


Anthony Liguori


reply via email to

[Prev in Thread] Current Thread [Next in Thread]