|
From: | Avi Kivity |
Subject: | Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device |
Date: | Thu, 25 Feb 2010 19:11:28 +0200 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) Gecko/20100120 Fedora/3.0.1-1.fc12 Thunderbird/3.0.1 |
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.
-- Do not meddle in the internals of kernels, for they are subtle and quick to panic.
[Prev in Thread] | Current Thread | [Next in Thread] |