From: Manfred Schlaegl <[email protected]>
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.
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.
Signed-off-by: Manfred Schlaegl <[email protected]>
Signed-off-by: Martin Kepplinger <[email protected]>
---
Is there any reason for this _limit_ to be as small as 64K?
thanks,
martin
drivers/tty/tty_buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 77070c2d1240..ec145a59f199 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -26,7 +26,7 @@
* Byte threshold to limit memory consumption for flip buffers.
* The actual memory limit is > 2x this amount.
*/
-#define TTYB_DEFAULT_MEM_LIMIT 65536
+#define TTYB_DEFAULT_MEM_LIMIT (640 * 1024UL)
/*
* We default to dicing tty buffer allocations to this many characters
--
2.20.1
On Mon, Jan 28, 2019 at 05:38:43PM +0100, Martin Kepplinger wrote:
> From: Manfred Schlaegl <[email protected]>
>
> 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?
> 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?
> Signed-off-by: Manfred Schlaegl <[email protected]>
> Signed-off-by: Martin Kepplinger <[email protected]>
> ---
>
> Is there any reason for this _limit_ to be as small as 64K?
Historical mostly from what I can tell.
thanks,
greg k-h
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 <[email protected]>
>>
>> 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 <[email protected]>
>> Signed-off-by: Martin Kepplinger <[email protected]>
>> ---
>>
>> 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