From mboxrd@z Thu Jan 1 00:00:00 1970 From: Johan Hovold Subject: Re: Regression: ftdi_sio is slow (since Wed Oct 10 15:05:06 2012) Date: Sat, 4 May 2013 13:15:35 +0200 Message-ID: <20130504111535.GC16818@localhost> References: <5183D196.2080305@list.ru> <20130503163008.GA30699@kroah.com> <5183F62A.1020801@list.ru> <20130503165231.GA1966@kroah.com> <5183FC83.8090602@list.ru> <20130503171618.GA16686@kroah.com> <51840186.7000608@list.ru> <20130503203419.GA25932@kroah.com> <51843132.9040304@list.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-la0-f43.google.com ([209.85.215.43]:57765 "EHLO mail-la0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756339Ab3EDLPk (ORCPT ); Sat, 4 May 2013 07:15:40 -0400 Content-Disposition: inline In-Reply-To: <51843132.9040304@list.ru> Sender: linux-serial-owner@vger.kernel.org List-Id: linux-serial@vger.kernel.org To: Stas Sergeev , Greg KH Cc: Jarkko Huijts , Alan Cox , linux-usb@vger.kernel.org, linux-serial@vger.kernel.org, Linux kernel , Caylan Van Larson , "Rafael J. Wysocki" On Sat, May 04, 2013 at 01:50:42AM +0400, Stas Sergeev wrote: > 04.05.2013 00:34, Greg KH =D0=BF=D0=B8=D1=88=D0=B5=D1=82: > > On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote: > >> 03.05.2013 21:16, Greg KH =D0=BF=D0=B8=D1=88=D0=B5=D1=82: [...] > >>> There's no guarantee as to how long select or an ioctl will take,= and > >>> now that we have fixed another bug, this device is slower. > >>> > >>> If you change hardware types to use a different usb to serial chi= p, that > >>> select call might take 4 times as long. Are we somehow supposed = to > >>> change the kernel to "fix" that? > >> Previously, the kernel was not calling to a device at all, so > >> select() was independent of the chip, and it was fast. I was > >> not aware you changed that willingly. > > I don't understand, what do you mean by this? Some drivers just re= turn > > the value of an internally held number, and don't query the device. > > > > The only way the FTDI driver can determine if the hardware buffer o= n the > > chip way out on the end of the USB cable is empty or not, is to que= ry > > it. So the driver now does so. > It does so only for one char. And the query takes longer than > to just xmit that char. So why do you think this even works as > expected? The query takes longer than the transmit at decent baudrates (>=3D38k) and under the assumption that flow control isn't causing any delays. But you do have a point, and I have been meaning to look into whether the added overhead of checking the hardware buffers could be mitigated by adding wait_until_sent support to usb-serial. This way the we would only query the hardware buffers on tty_wait_until_sent (e.g. at close) and select and TIOCMOUTQ would not suffer. This is also the way things are handled in serial_core. I'll prepare a series which adds wait_until_sent to usb-serial, but I doubt it would be stable material (even if it could get into 3.10). What do you think Greg, is this overhead to chars_in_buffer reason enough to disable it in the stable trees or should we simply fix it in 3.11 (or 3.10)? (The overhead is about 3-400 us per call when the port fifo is empty, which makes chars_in_buffer about 100 times slower on my test system.) Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-serial"= in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html