mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Martin Kepplinger <martink@posteo.de>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: jslaby@suse.com, linux-kernel@vger.kernel.org,
	Manfred Schlaegl <manfred.schlaegl@ginzinger.com>,
	Martin Kepplinger <martin.kepplinger@ginzinger.com>
Subject: Re: [PATCH] tty: increase the default flip buffer limit to 2*640K
Date: Mon, 28 Jan 2019 18:25:10 +0100	[thread overview]
Message-ID: <9a8ab1dffec11a4f9d98240d836bf45a@posteo.de> (raw)
In-Reply-To: <20190128165318.GA16213@kroah.com>

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 <manfred.schlaegl@ginzinger.com>
>> 
>> 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 <manfred.schlaegl@ginzinger.com>
>> Signed-off-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
>> ---
>> 
>> 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


      reply	other threads:[~2019-01-28 17:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-28 16:38 Martin Kepplinger
2019-01-28 16:53 ` Greg KH
2019-01-28 17:25   ` Martin Kepplinger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9a8ab1dffec11a4f9d98240d836bf45a@posteo.de \
    --to=martink@posteo.de \
    --cc=gregkh@linuxfoundation.org \
    --cc=jslaby@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred.schlaegl@ginzinger.com \
    --cc=martin.kepplinger@ginzinger.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome