|
From: | Anthony Liguori |
Subject: | Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device |
Date: | Thu, 25 Feb 2010 11:15:48 -0600 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0 |
On 02/25/2010 11:11 AM, Avi Kivity wrote:
On 02/25/2010 05:06 PM, Paul Brook wrote: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 shouldIdle bottom halves (i.e. qemu_bh_schedule_idle) are just bugs waiting tohappen, 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 inan 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).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
[Prev in Thread] | Current Thread | [Next in Thread] |