Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3710043imu; Mon, 28 Jan 2019 09:25:32 -0800 (PST) X-Google-Smtp-Source: ALg8bN6rZQsJW/eGAGheTAnZH5N6nLYQBlyO0QiU4imFq3uCQwhrWoarrhqcDLiAOf/Lr5een9GJ X-Received: by 2002:a17:902:7005:: with SMTP id y5mr22730841plk.7.1548696332633; Mon, 28 Jan 2019 09:25:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548696332; cv=none; d=google.com; s=arc-20160816; b=Yb1ry0LqEG6ZbGatwUsCQ4oNw9adX1JHcI25CxsT7wCyZtz9bvLXT3DgCb3HWcFqL3 aJ9ftzO/2QxSkGu/jdqc7rcAG7kbyJUCBUHmpkJFxMWVJheF0O9iU1XLznEBnKzNK8Mj w7knZYVe4oxT0xKpvZ932iGgEOmhII1u85Va0QVwWdeRjECoqEoAQoG3YaJBWLp0oXGt xZQIr4uJubiEQHIMb+guhibVB5xMrshcRSHaLMJCbE3S0rB2Mw2/E4ZJXZijih577ERQ dsH8anZnD4aVGYyB9CQwGHMdI7hGUFVw56MUWqUZGypH8rbWT1TUxsBrfk0Rwrljvyyb Iz2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature; bh=QtRPNYqm6ePpJ7/hnpc62KstoyEdhi8/SzrZICwMT8M=; b=QyZjfy2QhjD4gk1stoHrDyYqSvyFzv+P5dLF2QDEEtNhnW/V/0MsN86h4j8G4V5Qp3 b6IKWFmj9BDgSxRoTWS97ttCsHvnAjLFv+aSvw/GeYcFbqS+Jn9p7e8nwidUBJ6CXg21 gpWpl6dkn7V4n3ovvhvV0G2rQgIgpyF2krYzO2dGPkVeVnnAMRuQOal0bfIoTL99motC 4exTk4gDZjGTokrTU+2+RJRTWfquY5ggfeNAc9zFBLGaXux/tPe9fatt5Rxk1VlQVCWR hBDa2hyZHtFqnGodVrfdfFIREPXJqVAVWDUuxX9bOk6qBAz+uNNcaN885HoD39lKNUZe XWbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@posteo.de header.s=2017 header.b=X+EBiYWC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=posteo.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id i96si33554742plb.188.2019.01.28.09.25.17; Mon, 28 Jan 2019 09:25:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@posteo.de header.s=2017 header.b=X+EBiYWC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=posteo.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731048AbfA1RZQ (ORCPT + 99 others); Mon, 28 Jan 2019 12:25:16 -0500 Received: from mout01.posteo.de ([185.67.36.65]:56612 "EHLO mout01.posteo.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730411AbfA1RZO (ORCPT ); Mon, 28 Jan 2019 12:25:14 -0500 Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 50DB716005D for ; Mon, 28 Jan 2019 18:25:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1548696311; bh=73wo2EizwjgJieNSVPR9D53sKY2XisMDGFbCR2FPscg=; h=Date:From:To:Cc:Subject:From; b=X+EBiYWCDxx9FlXU/VpTLh5aijonu8T4FUo2+ozy/xizc5Tjv8Hwo8LRA9yLgMSxY mFMSafOcUgX/O3cCVaQoMmcG6OJDVmZVbzDteEepMVdTXHQ86A5u93lSG+/ZGWjw2k XEcVCzjIp7vtas3kuN7IByrdEu2+3kMRUlrXEw+OOw1bd1rh3Mtgje2f8f3VYL2kqS hZe3mWKb88fb1bM/nBPJX1hSaOIicrmimdE8okhEfL2Z1AdYCfyHQEHl92KU3TwRmc hgE+9cDiuThJpvnCmzkBjtO+EC3C92XAyKeesgez07AHuYeQpx2ZaFNHHYO4QxrlOe 4wrWgwT15OHOg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 43pGjL43Cwz6tmD; Mon, 28 Jan 2019 18:25:10 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 28 Jan 2019 18:25:10 +0100 From: Martin Kepplinger To: Greg KH Cc: jslaby@suse.com, linux-kernel@vger.kernel.org, Manfred Schlaegl , Martin Kepplinger Subject: Re: [PATCH] tty: increase the default flip buffer limit to 2*640K In-Reply-To: <20190128165318.GA16213@kroah.com> References: <20190128163843.688-1-martink@posteo.de> <20190128165318.GA16213@kroah.com> Message-ID: <9a8ab1dffec11a4f9d98240d836bf45a@posteo.de> X-Sender: martink@posteo.de User-Agent: Posteo Webmail Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Am 28.01.2019 17:53 schrieb Greg KH: > On Mon, Jan 28, 2019 at 05:38:43PM +0100, Martin Kepplinger wrote: >> From: Manfred Schlaegl >> >> The default value for this was 64K. We increase this by a factor of >> 10 to 640K to prevent data loss when using fast serial interfaces. > > What fast serial interface are you using where you run into this limit? RS485 without flow-control. At speeds of 1Mbit/s an upwards we've run into problems such as applications being too slow to read out this buffer (on embedded devices based on imx53 or imx6). If you want to write transmitted data to a slow SD card and thus have realtime requirements, this limit can become a problem. That shouldn't be the case and 640K buffers fix such problems for us. > >> Since this value is only a maximum limit for allocation and isn't used >> by default, this change has minimal effect on systems with slow >> interfaces. > > So what systems does it affect? This was misleading, sorry. This has no effect on systems that currently run fine I _think_. If transmission is slow enough, applications and hardware can keep up and increasing this limit won't have any effect. It only _allows_ to allocate more than 2*64K in cases we currently fail to allocate anything despite having memory available. > >> Signed-off-by: Manfred Schlaegl >> Signed-off-by: Martin Kepplinger >> --- >> >> Is there any reason for this _limit_ to be as small as 64K? > > Historical mostly from what I can tell. > > thanks, thanks for having a look, martin