From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JNjta-0005Af-JG for qemu-devel@nongnu.org; Sat, 09 Feb 2008 02:13:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JNjtY-00059w-2x for qemu-devel@nongnu.org; Sat, 09 Feb 2008 02:13:05 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JNjtX-00059t-QA for qemu-devel@nongnu.org; Sat, 09 Feb 2008 02:13:03 -0500 Received: from terminus.zytor.com ([198.137.202.10]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JNjtX-0007Hd-GT for qemu-devel@nongnu.org; Sat, 09 Feb 2008 02:13:03 -0500 Message-ID: <47AD524C.2070508@zytor.com> Date: Fri, 08 Feb 2008 23:12:12 -0800 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: 2.6.24 says "serial8250: too much work for irq4" a lot. References: <200802051455.10831.rob@landley.net> <200802071413.45085.rob@landley.net> <47AB75EB.3040405@zytor.com> <200802082349.34301.rob@landley.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org Blue Swirl wrote: > On 2/9/08, Rob Landley wrote: >> Here's a patch Peter Anvin wrote so the serial I/O doesn't flood the kernel. > > The patch looks OK, but the throttling should benefit all devices, as > discussed here: > http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00283.html I strongly disagree with the sentiments in that post. This is not a matter of rate throttling, but simulated FIFO exhaustion -- they are NOT the same thing. Simulated FIFO exhaustion is functionally equivalent to making sure there are interrupt windows opened in an otherwise-too-long critical section; it doesn't constrain any particular flow rate, as it still permits another interrupt to immediately come in. If you look at the patch, there are no timing dependencies; the only parameter is the depth of the virtual queue. The exhaustion is completely controlled by target OS access patterns. -hpa