Received: by 2002:a05:6a10:af89:0:0:0:0 with SMTP id iu9csp616056pxb; Fri, 28 Jan 2022 06:34:00 -0800 (PST) X-Google-Smtp-Source: ABdhPJxojFlcJlzCvOCNT7fHgns+gElDA588a1RkH/QkxtBLxF0ChXQJIHSrKHWnPqpK0YRkvPOu X-Received: by 2002:a17:90b:102:: with SMTP id p2mr10199053pjz.84.1643380440311; Fri, 28 Jan 2022 06:34:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643380440; cv=none; d=google.com; s=arc-20160816; b=k3e51RxYzrJ7ajfbC/SaY/B6BWEhLOC+HGSR2hBLKun4fBrUkPbTzZAP6pJ7S7DZbd A7LrFoiM9CM7LXygQGw11FOOzP8J3T0SG+LwH5CRFqsafm6qMrUbp0gBAmdOcRCykz97 uvxdqafkH71WKGZLK+++ccx9pYF3JCpW0p47EcD3HjKAXbkGybmva92GffI9DgR24vxe w5zYCFBuWC3a9yjnqIlmovNeNmO/2JuXJP+LMTqMZHZkqgCYuXpykCHxPC+9TVdxCX0N 3XxG/2LfKd8jYVnWbgZayZfvFGHkk03QWyQz99rk+xdrpcxmiuxus01cBmpc5S+4RWhQ +PMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=sN8WPe9C8g6nXFW4hxcMBRO9flHc7o3se2fSuyHJn7g=; b=djjrgO8IxLzmMrQSL3p1FkAvjNTCcJxUkMYREkb7UJMhK6iULo8YqLP/8BSpyLgw1S lfshZGNyQcn9TI4PnuCoT0K3mrTR1LG+8f/Fv4WjiczOoXvTCPAxPwL9dAwiF6LesubU zVVqWcX+/525fBWTNw6+baPJu2EZHTYtwjVu9PQLT9LBxdOC/tHasrk57/BjGekxeMm2 qvggJtiwqTmi4d6XC5faCwpB6RhLsFmIQ6VRB7QnNrv5FF+X6ylL6ug5UEYJ0EQT4CRi iAp6+ibkDJwzKJ6LvtH+4lP2m4+6pYjtSAH9Bq52ye/DQh9rxAvxycDlVx5XH+eDbgLy xTlg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i70si1142747pge.436.2022.01.28.06.33.48; Fri, 28 Jan 2022 06:34:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=mit.edu Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245503AbiA0SLS (ORCPT + 99 others); Thu, 27 Jan 2022 13:11:18 -0500 Received: from outgoing-auth-1.mit.edu ([18.9.28.11]:54622 "EHLO outgoing.mit.edu" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S244950AbiA0SKp (ORCPT ); Thu, 27 Jan 2022 13:10:45 -0500 Received: from callcc.thunk.org (static-74-43-95-34.fnd.frontiernet.net [74.43.95.34]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20RIAF2r014158 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jan 2022 13:10:17 -0500 Received: by callcc.thunk.org (Postfix, from userid 15806) id 64CBB420385; Thu, 27 Jan 2022 13:10:15 -0500 (EST) Date: Thu, 27 Jan 2022 13:10:15 -0500 From: "Theodore Y. Ts'o" To: Greg Kroah-Hartman Cc: Wander Costa , Andy Shevchenko , Jon Hunter , Jiri Slaby , Wander Lairson Costa , "Maciej W. Rozycki" , Johan Hovold , Andrew Jeffery , "open list:SERIAL DRIVERS" , open list , "linux-tegra@vger.kernel.org" Subject: Re: [PATCH] tty: serial: Use fifo in 8250 console driver Message-ID: References: <8e57400f-d6a8-bd42-6214-fca1fe37a972@kernel.org> <11ec4350-b890-4949-cf8f-bc62d530d64f@nvidia.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jan 26, 2022 at 09:52:26AM +0100, Greg Kroah-Hartman wrote: > > Let me revert this for now. And no new config options please, this > should "just work". I'm not sure the commit is actually worth the extra complexity, to be honest. The reason for the FIFO is to improve interrupt latency, and in the console write path, we're busy looping. There is something seriously wrong serial port of the HP Proliant DL380 Gen 9. Per the commit description for 5021d709b31b: ("tty: serial: Use fifo in 8250 console driver"), on the "fast machine" (read: the one with a propertly working serial port), we were getting over 10 KB/s without the patch. And on the "slow machine" it was getting only 2.5 KB/s, and with the patch it only improved things by 25% (so only 3.1 KB/s). I assume what must be going on is this machine is emulating the UART and is extremely slow to set the Trasmitter Holding Register Empty (THRE) bit after the UART is finished sending the byte out the serial port. So we're adding a lot of complexity for what is obviously broken hardware, and we risk breaking the serial console for other machines with a properly implemented serial port. How common are UART's which are broken in this way? Is it unique to the HP Proliant DL380 Gen 9? Or is a common misimplementation which is unfortunately quite common? If it's the former, maybe the FIFO hack should only be done via a quirk? If it's really the case that the HP Proliant's nasty performance is due to a badly implemented emulation layer, is there any way to do better, perhaps via a more direct path to the serial port? Or is the problem that the serial port on this motherboard is connected via some super-slow internal path and it would be faster if you could talk to it directly via a UEFI call, or some other mechanism? Whether it's 2.5 KB/s or 3.1 KB/s, it's really quite pathetic.... - Ted