All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] tty: Fix low_latency BUG
@ 2014-02-22 12:31 ` Peter Hurley
  0 siblings, 0 replies; 9+ messages in thread
From: Peter Hurley @ 2014-02-22 12:31 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Jiri Slaby, linux-serial, Beat Bolli, Pavel Roskin, linux-kernel,
	Jiri Kosina, David Sterba, Felipe Balbi, Peter Hurley,
	Grant Edwards, Stanislaw Gruszka, Hal Murray, Alan Cox, stable

The user-settable knob, low_latency, has been the source of
several BUG reports which stem from flush_to_ldisc() running
in interrupt context. Since 3.12, which added several sleeping
locks (termios_rwsem and buf->lock) to the input processing path,
the frequency of these BUG reports has increased.

Note that changes in 3.12 did not introduce this regression;
sleeping locks were first added to the input processing path
with the removal of the BKL from N_TTY in commit
a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc,
'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
and later in commit 38db89799bdf11625a831c5af33938dcb11908b6,
'tty: throttling race fix'. Since those changes, executing
flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.

However, since most devices do not validate if the low_latency
setting is appropriate for the context (process or interrupt) in
which they receive data, some reports are due to misconfiguration.
Further, serial dma devices for which dma fails, resort to
interrupt receiving as a backup without resetting low_latency.

Historically, low_latency was used to force wake-up the reading
process rather than wait for the next scheduler tick. The
effect was to trim multiple milliseconds of latency from
when the process would receive new data.

Recent tests [1] have shown that the reading process now receives
data with only 10's of microseconds latency without low_latency set.

Remove the low_latency rx steering from tty_flip_buffer_push();
however, leave the knob as an optional hint to drivers that can
tune their rx fifos and such like. Cleanup stale code comments
regarding low_latency.

[1] https://lkml.org/lkml/2014/2/20/434

Reported-by: Beat Bolli <bbolli@ewanet.ch>
Reported-by: Pavel Roskin <proski@gnu.org>
Cc: Grant Edwards <grant.b.edwards@gmail.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Hal Murray <murray+fedora@ip-64-139-1-69.sjc.megapath.net>
Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org> # 3.12.x+
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
---
 drivers/tty/ipwireless/tty.c  |  3 ---
 drivers/tty/tty_buffer.c      | 20 ++++----------------
 drivers/usb/gadget/u_serial.c |  4 ++--
 include/linux/tty.h           |  2 +-
 4 files changed, 7 insertions(+), 22 deletions(-)

diff --git a/drivers/tty/ipwireless/tty.c b/drivers/tty/ipwireless/tty.c
index ebd5bff..17ee3bf 100644
--- a/drivers/tty/ipwireless/tty.c
+++ b/drivers/tty/ipwireless/tty.c
@@ -176,9 +176,6 @@ void ipwireless_tty_received(struct ipw_tty *tty, unsigned char *data,
 				": %d chars not inserted to flip buffer!\n",
 				length - work);
 
-	/*
-	 * This may sleep if ->low_latency is set
-	 */
 	if (work)
 		tty_flip_buffer_push(&tty->port);
 }
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 765125d..8ebd9f8 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -351,14 +351,11 @@ EXPORT_SYMBOL(tty_insert_flip_string_flags);
  *	Takes any pending buffers and transfers their ownership to the
  *	ldisc side of the queue. It then schedules those characters for
  *	processing by the line discipline.
- *	Note that this function can only be used when the low_latency flag
- *	is unset. Otherwise the workqueue won't be flushed.
  */
 
 void tty_schedule_flip(struct tty_port *port)
 {
 	struct tty_bufhead *buf = &port->buf;
-	WARN_ON(port->low_latency);
 
 	buf->tail->commit = buf->tail->used;
 	schedule_work(&buf->work);
@@ -482,17 +479,15 @@ static void flush_to_ldisc(struct work_struct *work)
  */
 void tty_flush_to_ldisc(struct tty_struct *tty)
 {
-	if (!tty->port->low_latency)
-		flush_work(&tty->port->buf.work);
+	flush_work(&tty->port->buf.work);
 }
 
 /**
  *	tty_flip_buffer_push	-	terminal
  *	@port: tty port to push
  *
- *	Queue a push of the terminal flip buffers to the line discipline. This
- *	function must not be called from IRQ context if port->low_latency is
- *	set.
+ *	Queue a push of the terminal flip buffers to the line discipline.
+ *	Can be called from IRQ/atomic context.
  *
  *	In the event of the queue being busy for flipping the work will be
  *	held off and retried later.
@@ -500,14 +495,7 @@ void tty_flush_to_ldisc(struct tty_struct *tty)
 
 void tty_flip_buffer_push(struct tty_port *port)
 {
-	struct tty_bufhead *buf = &port->buf;
-
-	buf->tail->commit = buf->tail->used;
-
-	if (port->low_latency)
-		flush_to_ldisc(&buf->work);
-	else
-		schedule_work(&buf->work);
+	tty_schedule_flip(port);
 }
 EXPORT_SYMBOL(tty_flip_buffer_push);
 
diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
index b369292..ad0aca8 100644
--- a/drivers/usb/gadget/u_serial.c
+++ b/drivers/usb/gadget/u_serial.c
@@ -549,8 +549,8 @@ static void gs_rx_push(unsigned long _port)
 		port->read_started--;
 	}
 
-	/* Push from tty to ldisc; without low_latency set this is handled by
-	 * a workqueue, so we won't get callbacks and can hold port_lock
+	/* Push from tty to ldisc; this is handled by a workqueue,
+	 * so we won't get callbacks and can hold port_lock
 	 */
 	if (do_push)
 		tty_flip_buffer_push(&port->port);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 4781d7b..1c3316a 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -208,7 +208,7 @@ struct tty_port {
 	wait_queue_head_t	delta_msr_wait;	/* Modem status change */
 	unsigned long		flags;		/* TTY flags ASY_*/
 	unsigned char		console:1,	/* port is a console */
-				low_latency:1;	/* direct buffer flush */
+				low_latency:1;	/* optional: tune for latency */
 	struct mutex		mutex;		/* Locking */
 	struct mutex		buf_mutex;	/* Buffer alloc lock */
 	unsigned char		*xmit_buf;	/* Optional buffer */
-- 
1.8.1.2


^ permalink raw reply related	[flat|nested] 9+ messages in thread

* [PATCH] tty: Fix low_latency BUG
@ 2014-02-22 12:31 ` Peter Hurley
  0 siblings, 0 replies; 9+ messages in thread
From: Peter Hurley @ 2014-02-22 12:31 UTC (permalink / raw)
  To: Greg Kroah-Hartman
  Cc: Jiri Slaby, linux-serial, Beat Bolli, Pavel Roskin, linux-kernel,
	Jiri Kosina, David Sterba, Felipe Balbi, Peter Hurley,
	Grant Edwards, Stanislaw Gruszka, Hal Murray, Alan Cox, stable

The user-settable knob, low_latency, has been the source of
several BUG reports which stem from flush_to_ldisc() running
in interrupt context. Since 3.12, which added several sleeping
locks (termios_rwsem and buf->lock) to the input processing path,
the frequency of these BUG reports has increased.

Note that changes in 3.12 did not introduce this regression;
sleeping locks were first added to the input processing path
with the removal of the BKL from N_TTY in commit
a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc,
'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
and later in commit 38db89799bdf11625a831c5af33938dcb11908b6,
'tty: throttling race fix'. Since those changes, executing
flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.

However, since most devices do not validate if the low_latency
setting is appropriate for the context (process or interrupt) in
which they receive data, some reports are due to misconfiguration.
Further, serial dma devices for which dma fails, resort to
interrupt receiving as a backup without resetting low_latency.

Historically, low_latency was used to force wake-up the reading
process rather than wait for the next scheduler tick. The
effect was to trim multiple milliseconds of latency from
when the process would receive new data.

Recent tests [1] have shown that the reading process now receives
data with only 10's of microseconds latency without low_latency set.

Remove the low_latency rx steering from tty_flip_buffer_push();
however, leave the knob as an optional hint to drivers that can
tune their rx fifos and such like. Cleanup stale code comments
regarding low_latency.

[1] https://lkml.org/lkml/2014/2/20/434

Reported-by: Beat Bolli <bbolli@ewanet.ch>
Reported-by: Pavel Roskin <proski@gnu.org>
Cc: Grant Edwards <grant.b.edwards@gmail.com>
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Hal Murray <murray+fedora@ip-64-139-1-69.sjc.megapath.net>
Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: <stable@vger.kernel.org> # 3.12.x+
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
---
 drivers/tty/ipwireless/tty.c  |  3 ---
 drivers/tty/tty_buffer.c      | 20 ++++----------------
 drivers/usb/gadget/u_serial.c |  4 ++--
 include/linux/tty.h           |  2 +-
 4 files changed, 7 insertions(+), 22 deletions(-)

diff --git a/drivers/tty/ipwireless/tty.c b/drivers/tty/ipwireless/tty.c
index ebd5bff..17ee3bf 100644
--- a/drivers/tty/ipwireless/tty.c
+++ b/drivers/tty/ipwireless/tty.c
@@ -176,9 +176,6 @@ void ipwireless_tty_received(struct ipw_tty *tty, unsigned char *data,
 				": %d chars not inserted to flip buffer!\n",
 				length - work);
 
-	/*
-	 * This may sleep if ->low_latency is set
-	 */
 	if (work)
 		tty_flip_buffer_push(&tty->port);
 }
diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index 765125d..8ebd9f8 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -351,14 +351,11 @@ EXPORT_SYMBOL(tty_insert_flip_string_flags);
  *	Takes any pending buffers and transfers their ownership to the
  *	ldisc side of the queue. It then schedules those characters for
  *	processing by the line discipline.
- *	Note that this function can only be used when the low_latency flag
- *	is unset. Otherwise the workqueue won't be flushed.
  */
 
 void tty_schedule_flip(struct tty_port *port)
 {
 	struct tty_bufhead *buf = &port->buf;
-	WARN_ON(port->low_latency);
 
 	buf->tail->commit = buf->tail->used;
 	schedule_work(&buf->work);
@@ -482,17 +479,15 @@ static void flush_to_ldisc(struct work_struct *work)
  */
 void tty_flush_to_ldisc(struct tty_struct *tty)
 {
-	if (!tty->port->low_latency)
-		flush_work(&tty->port->buf.work);
+	flush_work(&tty->port->buf.work);
 }
 
 /**
  *	tty_flip_buffer_push	-	terminal
  *	@port: tty port to push
  *
- *	Queue a push of the terminal flip buffers to the line discipline. This
- *	function must not be called from IRQ context if port->low_latency is
- *	set.
+ *	Queue a push of the terminal flip buffers to the line discipline.
+ *	Can be called from IRQ/atomic context.
  *
  *	In the event of the queue being busy for flipping the work will be
  *	held off and retried later.
@@ -500,14 +495,7 @@ void tty_flush_to_ldisc(struct tty_struct *tty)
 
 void tty_flip_buffer_push(struct tty_port *port)
 {
-	struct tty_bufhead *buf = &port->buf;
-
-	buf->tail->commit = buf->tail->used;
-
-	if (port->low_latency)
-		flush_to_ldisc(&buf->work);
-	else
-		schedule_work(&buf->work);
+	tty_schedule_flip(port);
 }
 EXPORT_SYMBOL(tty_flip_buffer_push);
 
diff --git a/drivers/usb/gadget/u_serial.c b/drivers/usb/gadget/u_serial.c
index b369292..ad0aca8 100644
--- a/drivers/usb/gadget/u_serial.c
+++ b/drivers/usb/gadget/u_serial.c
@@ -549,8 +549,8 @@ static void gs_rx_push(unsigned long _port)
 		port->read_started--;
 	}
 
-	/* Push from tty to ldisc; without low_latency set this is handled by
-	 * a workqueue, so we won't get callbacks and can hold port_lock
+	/* Push from tty to ldisc; this is handled by a workqueue,
+	 * so we won't get callbacks and can hold port_lock
 	 */
 	if (do_push)
 		tty_flip_buffer_push(&port->port);
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 4781d7b..1c3316a 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -208,7 +208,7 @@ struct tty_port {
 	wait_queue_head_t	delta_msr_wait;	/* Modem status change */
 	unsigned long		flags;		/* TTY flags ASY_*/
 	unsigned char		console:1,	/* port is a console */
-				low_latency:1;	/* direct buffer flush */
+				low_latency:1;	/* optional: tune for latency */
 	struct mutex		mutex;		/* Locking */
 	struct mutex		buf_mutex;	/* Buffer alloc lock */
 	unsigned char		*xmit_buf;	/* Optional buffer */
-- 
1.8.1.2

^ permalink raw reply related	[flat|nested] 9+ messages in thread

* Re: [PATCH] tty: Fix low_latency BUG
  2014-02-22 12:31 ` Peter Hurley
@ 2014-02-22 21:56   ` One Thousand Gnomes
  -1 siblings, 0 replies; 9+ messages in thread
From: One Thousand Gnomes @ 2014-02-22 21:56 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Beat Bolli,
	Pavel Roskin, linux-kernel, Jiri Kosina, David Sterba,
	Felipe Balbi, Grant Edwards, Stanislaw Gruszka, Hal Murray,
	stable

> Remove the low_latency rx steering from tty_flip_buffer_push();
> however, leave the knob as an optional hint to drivers that can
> tune their rx fifos and such like. Cleanup stale code comments
> regarding low_latency.
> 
> [1] https://lkml.org/lkml/2014/2/20/434
> 
> Reported-by: Beat Bolli <bbolli@ewanet.ch>
> Reported-by: Pavel Roskin <proski@gnu.org>
> Cc: Grant Edwards <grant.b.edwards@gmail.com>
> Cc: Stanislaw Gruszka <sgruszka@redhat.com>
> Cc: Hal Murray <murray+fedora@ip-64-139-1-69.sjc.megapath.net>
> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
> Cc: <stable@vger.kernel.org> # 3.12.x+
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>

Signed-off-by: Alan Cox <alan@linux.intel.com>

Yay.. thats an annoying historical pain in the butt gone.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] tty: Fix low_latency BUG
@ 2014-02-22 21:56   ` One Thousand Gnomes
  0 siblings, 0 replies; 9+ messages in thread
From: One Thousand Gnomes @ 2014-02-22 21:56 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Beat Bolli,
	Pavel Roskin, linux-kernel, Jiri Kosina, David Sterba,
	Felipe Balbi, Grant Edwards, Stanislaw Gruszka, Hal Murray,
	stable

> Remove the low_latency rx steering from tty_flip_buffer_push();
> however, leave the knob as an optional hint to drivers that can
> tune their rx fifos and such like. Cleanup stale code comments
> regarding low_latency.
> 
> [1] https://lkml.org/lkml/2014/2/20/434
> 
> Reported-by: Beat Bolli <bbolli@ewanet.ch>
> Reported-by: Pavel Roskin <proski@gnu.org>
> Cc: Grant Edwards <grant.b.edwards@gmail.com>
> Cc: Stanislaw Gruszka <sgruszka@redhat.com>
> Cc: Hal Murray <murray+fedora@ip-64-139-1-69.sjc.megapath.net>
> Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
> Cc: <stable@vger.kernel.org> # 3.12.x+
> Signed-off-by: Peter Hurley <peter@hurleysoftware.com>

Signed-off-by: Alan Cox <alan@linux.intel.com>

Yay.. thats an annoying historical pain in the butt gone.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] tty: Fix low_latency BUG
  2014-02-22 12:31 ` Peter Hurley
  (?)
  (?)
@ 2014-02-24 13:02 ` David Sterba
  -1 siblings, 0 replies; 9+ messages in thread
From: David Sterba @ 2014-02-24 13:02 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Beat Bolli,
	Pavel Roskin, linux-kernel, Jiri Kosina, Felipe Balbi,
	Grant Edwards, Stanislaw Gruszka, Hal Murray, Alan Cox, stable

On Sat, Feb 22, 2014 at 07:31:21AM -0500, Peter Hurley wrote:
> --- a/drivers/tty/ipwireless/tty.c
> +++ b/drivers/tty/ipwireless/tty.c
> @@ -176,9 +176,6 @@ void ipwireless_tty_received(struct ipw_tty *tty, unsigned char *data,
>  				": %d chars not inserted to flip buffer!\n",
>  				length - work);
>  
> -	/*
> -	 * This may sleep if ->low_latency is set
> -	 */

This is a no-op change for the ipwireless driver itself, nevertheless
here goes the maintainer's

Acked-by: David Sterba <dsterba@suse.cz>

>  	if (work)
>  		tty_flip_buffer_push(&tty->port);
>  }


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] tty: Fix low_latency BUG
  2014-02-22 12:31 ` Peter Hurley
                   ` (2 preceding siblings ...)
  (?)
@ 2014-02-26  5:11 ` Feng Tang
  2014-02-26 15:40   ` Peter Hurley
  -1 siblings, 1 reply; 9+ messages in thread
From: Feng Tang @ 2014-02-26  5:11 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Beat Bolli,
	Pavel Roskin, Linux Kernel Mailing List, Jiri Kosina,
	David Sterba, Felipe Balbi, Grant Edwards, Stanislaw Gruszka,
	Hal Murray, Alan Cox, stable

Hi Peter,

2014-02-22 20:31 GMT+08:00 Peter Hurley <peter@hurleysoftware.com>:
> The user-settable knob, low_latency, has been the source of
> several BUG reports which stem from flush_to_ldisc() running
> in interrupt context. Since 3.12, which added several sleeping
> locks (termios_rwsem and buf->lock) to the input processing path,
> the frequency of these BUG reports has increased.
>
> Note that changes in 3.12 did not introduce this regression;
> sleeping locks were first added to the input processing path
> with the removal of the BKL from N_TTY in commit
> a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc,
> 'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
> and later in commit 38db89799bdf11625a831c5af33938dcb11908b6,
> 'tty: throttling race fix'. Since those changes, executing
> flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.
>
> However, since most devices do not validate if the low_latency
> setting is appropriate for the context (process or interrupt) in
> which they receive data, some reports are due to misconfiguration.
> Further, serial dma devices for which dma fails, resort to
> interrupt receiving as a backup without resetting low_latency.
>
> Historically, low_latency was used to force wake-up the reading
> process rather than wait for the next scheduler tick. The
> effect was to trim multiple milliseconds of latency from
> when the process would receive new data.
>
> Recent tests [1] have shown that the reading process now receives
> data with only 10's of microseconds latency without low_latency set.

The 10's of miscroseconds is ok for 115200 bps like device, but it may
hurt the high speed device like Bluetooth which runs at 3M/4M bps or
higher.

More and more smartphones are using uart as the Bluetooth data
interface due to its low-pin, low-power feature, and many of them
are using HZ=100 kernel, I'm afraid this added delay may cause
some problem.

Thanks,
Feng

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] tty: Fix low_latency BUG
  2014-02-26  5:11 ` Feng Tang
@ 2014-02-26 15:40   ` Peter Hurley
  2014-02-27  3:28     ` Feng Tang
  0 siblings, 1 reply; 9+ messages in thread
From: Peter Hurley @ 2014-02-26 15:40 UTC (permalink / raw)
  To: Feng Tang
  Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Beat Bolli,
	Pavel Roskin, Linux Kernel Mailing List, Jiri Kosina,
	David Sterba, Felipe Balbi, Grant Edwards, Stanislaw Gruszka,
	Hal Murray, Alan Cox, stable, linux-bluetooth

[ +cc linux-bluetooth ]

Hi Feng,

On 02/26/2014 12:11 AM, Feng Tang wrote:
> Hi Peter,
>
> 2014-02-22 20:31 GMT+08:00 Peter Hurley <peter@hurleysoftware.com>:
>> The user-settable knob, low_latency, has been the source of
>> several BUG reports which stem from flush_to_ldisc() running
>> in interrupt context. Since 3.12, which added several sleeping
>> locks (termios_rwsem and buf->lock) to the input processing path,
>> the frequency of these BUG reports has increased.
>>
>> Note that changes in 3.12 did not introduce this regression;
>> sleeping locks were first added to the input processing path
>> with the removal of the BKL from N_TTY in commit
>> a88a69c91256418c5907c2f1f8a0ec0a36f9e6cc,
>> 'n_tty: Fix loss of echoed characters and remove bkl from n_tty'
>> and later in commit 38db89799bdf11625a831c5af33938dcb11908b6,
>> 'tty: throttling race fix'. Since those changes, executing
>> flush_to_ldisc() in interrupt_context (ie, low_latency set), is unsafe.
>>
>> However, since most devices do not validate if the low_latency
>> setting is appropriate for the context (process or interrupt) in
>> which they receive data, some reports are due to misconfiguration.
>> Further, serial dma devices for which dma fails, resort to
>> interrupt receiving as a backup without resetting low_latency.
>>
>> Historically, low_latency was used to force wake-up the reading
>> process rather than wait for the next scheduler tick. The
>> effect was to trim multiple milliseconds of latency from
>> when the process would receive new data.
>>
>> Recent tests [1] have shown that the reading process now receives
>> data with only 10's of microseconds latency without low_latency set.
>
> The 10's of miscroseconds is ok for 115200 bps like device, but it may
> hurt the high speed device like Bluetooth which runs at 3M/4M bps or
> higher.

The tests were run at 400Mbps, so 3Mbps or 4Mbps is not a problem
(but I think you may be confusing throughput with latency).

FWIW, two things affected the latency times of those particular tests;
1) the kernel firewire subsystem handles rx data in a tasklet (so not
    directly from IRQ) which negatively affected the latency reported, and
2) the ftrace instrumentation is not free and there are several traces per rx.

If you look carefully at the test trace data, you'll see that the timestamps
from tty_flip_buffer_push() of the rx data to n_tty_write() of the
response averages _~11us_; this is the measured latency from tty driver
receiving the rx data to reading of that data *and* the process
response (which comes back up through several tty locks).

Naturally, in mainline kernel, the scheduler load will affect the
measured latency *but that's true regardless of low_latency rx steering
because the user-space process must still be woken to complete the read*.

> More and more smartphones are using uart as the Bluetooth data
> interface due to its low-pin, low-power feature, and many of them
> are using HZ=100 kernel, I'm afraid this added delay may cause
> some problem.

Some hard data showing a real problem would help further this
discussion; my belief is that 3.12+ w/o low_latency rx steering
will outperform 3.11- w/ low_latency rx steering in every test.

I'm glad to hear that the Bluetooth uart interface is getting
some use; that means someone will soon be fixing the hard lockup
in hci_uart_tx_wakeup() reported here:

http://www.spinics.net/lists/linux-serial/msg11529.html

Regards,
Peter Hurley

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] tty: Fix low_latency BUG
  2014-02-26 15:40   ` Peter Hurley
@ 2014-02-27  3:28     ` Feng Tang
  2014-02-27  9:22       ` One Thousand Gnomes
  0 siblings, 1 reply; 9+ messages in thread
From: Feng Tang @ 2014-02-27  3:28 UTC (permalink / raw)
  To: Peter Hurley
  Cc: Greg Kroah-Hartman, Jiri Slaby, linux-serial, Beat Bolli,
	Pavel Roskin, Linux Kernel Mailing List, Jiri Kosina,
	David Sterba, Felipe Balbi, Grant Edwards, Stanislaw Gruszka,
	Hal Murray, Alan Cox, stable, linux-bluetooth, feng.tang,
	bin.yang, alek.du

Hi Peter,

2014-02-26 23:40 GMT+08:00 Peter Hurley <peter@hurleysoftware.com>:
> [ +cc linux-bluetooth ]

>>>
>>> Historically, low_latency was used to force wake-up the reading
>>> process rather than wait for the next scheduler tick. The
>>> effect was to trim multiple milliseconds of latency from
>>> when the process would receive new data.
>>>
>>> Recent tests [1] have shown that the reading process now receives
>>> data with only 10's of microseconds latency without low_latency set.
>>
>>
>> The 10's of miscroseconds is ok for 115200 bps like device, but it may
>> hurt the high speed device like Bluetooth which runs at 3M/4M bps or
>> higher.
>
>
> The tests were run at 400Mbps, so 3Mbps or 4Mbps is not a problem
> (but I think you may be confusing throughput with latency).

I wrote the serial driver for intel mid platforms which are widely used
in current smart phones, so I guess I know what I'm talking :)

Our test and customer test cover both the performance and latency.
say like transferring  2 GB file while using BT A2DP to playing music.

Also I heard there is some app which will do real time void/data
exchange with paired bluetooth, here microseconds really means
something.

>
> FWIW, two things affected the latency times of those particular tests;
> 1) the kernel firewire subsystem handles rx data in a tasklet (so not
>    directly from IRQ) which negatively affected the latency reported, and
> 2) the ftrace instrumentation is not free and there are several traces per
> rx.
>
> If you look carefully at the test trace data, you'll see that the timestamps
> from tty_flip_buffer_push() of the rx data to n_tty_write() of the
> response averages _~11us_; this is the measured latency from tty driver
> receiving the rx data to reading of that data *and* the process
> response (which comes back up through several tty locks).
>
> Naturally, in mainline kernel, the scheduler load will affect the
> measured latency *but that's true regardless of low_latency rx steering
> because the user-space process must still be woken to complete the read*.
>
>
>> More and more smartphones are using uart as the Bluetooth data
>> interface due to its low-pin, low-power feature, and many of them
>> are using HZ=100 kernel, I'm afraid this added delay may cause
>> some problem.
>
>
> Some hard data showing a real problem would help further this
> discussion; my belief is that 3.12+ w/o low_latency rx steering
> will outperform 3.11- w/ low_latency rx steering in every test.

As for measurements, I guess it should cover 2 parts:
1. the performance, like the BT file transfer data rate
2. the latency, like the real time BT communication

I'll try to get some test data soon. Also I'm wondering what devices
have you tested? regarding these 2 points.

>
> I'm glad to hear that the Bluetooth uart interface is getting
> some use; that means someone will soon be fixing the hard lockup
> in hci_uart_tx_wakeup() reported here:

I'm not very familiar with the BT devices on our platforms, but most
of them are not using the in-kernel BT driver, some just use the
n_tty ldisc and the raw data, some use their own ldisc driver.

Thanks,
Feng

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: [PATCH] tty: Fix low_latency BUG
  2014-02-27  3:28     ` Feng Tang
@ 2014-02-27  9:22       ` One Thousand Gnomes
  0 siblings, 0 replies; 9+ messages in thread
From: One Thousand Gnomes @ 2014-02-27  9:22 UTC (permalink / raw)
  To: Feng Tang
  Cc: Peter Hurley, Greg Kroah-Hartman, Jiri Slaby, linux-serial,
	Beat Bolli, Pavel Roskin, Linux Kernel Mailing List, Jiri Kosina,
	David Sterba, Felipe Balbi, Grant Edwards, Stanislaw Gruszka,
	Hal Murray, stable, linux-bluetooth, feng.tang, bin.yang,
	alek.du

> > I'm glad to hear that the Bluetooth uart interface is getting
> > some use; that means someone will soon be fixing the hard lockup
> > in hci_uart_tx_wakeup() reported here:
> 
> I'm not very familiar with the BT devices on our platforms, but most
> of them are not using the in-kernel BT driver, some just use the
> n_tty ldisc and the raw data, some use their own ldisc driver.

Outside of the world of phones/android the Bluetooth on quite a few of the
Baytrail/T devices is on the LPSS serial so it probably will be getting
tested sooner not later and there will actually be a common platform
around that is using the bluetooth uart features.

I'm not anticipating any problems though.

Alan

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-02-27  9:23 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-02-22 12:31 [PATCH] tty: Fix low_latency BUG Peter Hurley
2014-02-22 12:31 ` Peter Hurley
2014-02-22 21:56 ` One Thousand Gnomes
2014-02-22 21:56   ` One Thousand Gnomes
2014-02-24 13:02 ` David Sterba
2014-02-26  5:11 ` Feng Tang
2014-02-26 15:40   ` Peter Hurley
2014-02-27  3:28     ` Feng Tang
2014-02-27  9:22       ` One Thousand Gnomes

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.