Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933926AbZJMP7Y (ORCPT ); Tue, 13 Oct 2009 11:59:24 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933517AbZJMP7X (ORCPT ); Tue, 13 Oct 2009 11:59:23 -0400 Received: from earthlight.etchedpixels.co.uk ([81.2.110.250]:55734 "EHLO www.etchedpixels.co.uk" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933880AbZJMP7W convert rfc822-to-8bit (ORCPT ); Tue, 13 Oct 2009 11:59:22 -0400 Date: Tue, 13 Oct 2009 16:59:21 +0100 From: Alan Cox To: Linus Torvalds Cc: Paul Fulghum , Nix , "Justin P. Mattock" , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List , Boyan , Dmitry Torokhov , Ed Tomlinson , "=?ISO-8859-14?B?RnLpZOlyaWM=?= L. W. Meunier" , OGAWA Hirofumi Subject: Re: [Bug #14388] keyboard under X with 2.6.31 Message-ID: <20091013165921.4b0ffef5@lxorguk.ukuu.org.uk> In-Reply-To: References: <56acieJJ2fF.A.nEB.Hzl0KB@chimera> <87ljjgfcbu.fsf@spindle.srvr.nix> <20091013113232.384b2432@lxorguk.ukuu.org.uk> <1255447980.3898.3.camel@x2.microgate.com> X-Mailer: Claws Mail 3.7.2 (GTK+ 2.14.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-14 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2196 Lines: 43 > What I was pointing out is that there are a lot of > "tty_buffer_request_room()" calls, and as far as I can see, all of them > (or at least a large percentage) are just pure and utter crap. Almost certainly. When the original conversion was done all the code which tried to peer into the flip buffer and check what bytes were left was converted systematically to call request_room() as well in order to make the conversion easy and reliable. For most devices thats a fairly na?ve conversion as with the new buffering the tty device really shouldn't care about overruns. If we overrun now it's because we really do want to dump stuff not because of crappy buffering. The request_room actually trying to produce big buffers semantic was added because some of the high speed DMA based adapters (notably 3G USB ones) would hand large blocks of data over each time at rates upwards of 10-20Mbits. Without that request_room tweak they tended to drop data. Because of the way they work the DMA buffers are allocated when the URB is submitted so they can't use prepare_* ops but had to copy in some form. With those in place we top out at about 40-50Mbits over a USB serial link, which ought to be enough for anyone sane for the moment. Your change to tty_insert_flip_string() is irrelevant for any practical situation simply because the caller has to provide ordering of the blocks it submits (if it receives 5 bytes and they all queue asynchronously then it doesn't matter one iota whether tty_insert_flip_string has extra internal locking "linus" is still going to turn randomly into things like "sunil" in the serial stream and cause much confusion). I actually think you should make the tty_insert_flip_string internal length checking change because: - It makes the consistency of tty_insert_flip_string clearer to any future reader - It's a very very mindbogglingly slight performance win - It'll no doubt make you feel less grumpy ;) Alan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/