From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JNnfq-0005fj-2I for qemu-devel@nongnu.org; Sat, 09 Feb 2008 06:15:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JNnfp-0005fU-C0 for qemu-devel@nongnu.org; Sat, 09 Feb 2008 06:15:09 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JNnfp-0005fR-7a for qemu-devel@nongnu.org; Sat, 09 Feb 2008 06:15:09 -0500 Received: from fg-out-1718.google.com ([72.14.220.157]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JNnfp-0003QO-7O for qemu-devel@nongnu.org; Sat, 09 Feb 2008 06:15:09 -0500 Received: by fg-out-1718.google.com with SMTP id e12so3252731fga.8 for ; Sat, 09 Feb 2008 03:15:08 -0800 (PST) Message-ID: Date: Sat, 9 Feb 2008 13:15:07 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] Re: 2.6.24 says "serial8250: too much work for irq4" a lot. In-Reply-To: <47AD524C.2070508@zytor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200802051455.10831.rob@landley.net> <200802071413.45085.rob@landley.net> <47AB75EB.3040405@zytor.com> <200802082349.34301.rob@landley.net> <47AD524C.2070508@zytor.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "H. Peter Anvin" Cc: qemu-devel@nongnu.org On 2/9/08, H. Peter Anvin wrote: > 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. Thanks, this clarified the difference. But I'll rephrase my original comment: The patch looks OK, but the simulated FIFO exhaustion should benefit all devices, as discussed here: http://lists.gnu.org/archive/html/qemu-devel/2007-12/msg00283.html