linux-rt-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Esben Haabendal <esben.haabendal@gmail.com>
To: John Ogness <john.ogness@linutronix.de>
Cc: "André Pribil" <a.pribil@beck-ipc.com>,
	"linux-rt-users@vger.kernel.org" <linux-rt-users@vger.kernel.org>
Subject: Re: tty latency and RT
Date: Mon, 09 Jul 2018 11:55:08 +0200	[thread overview]
Message-ID: <87pnzwag3n.fsf@gmail.com> (raw)
In-Reply-To: <87muv4zpu8.fsf@linutronix.de> (John Ogness's message of "Fri, 06 Jul 2018 11:16:31 +0200")

John Ogness <john.ogness@linutronix.de> writes:

> Hi,
>
> On 2018-07-06, André Pribil <a.pribil@beck-ipc.com> wrote:
>> are there any plans to improve the latency with serial ttys and RT?
>>
>> I'm seeing very high latencies (up to 100 ms) when a high priority 
>> RT thread accesses a serial tty port. I'm working with 4.14.52-rt34 
>> on a ARM system.
>
> As you later point out, this is a problem with the tty subsystem
> (kworker) and is not RT-specific. This problem needs to be fixed in
> mainline.
>
>> The reason for this issue seems to be that a kworker thread with a 
>> normal priority is involved here. When the high priority RT 
>> thread needs to wait for this kworker thread, it can easily be blocked 
>> by other lower priority RT threads running in the system.
>>
>> I have seen that Steven Walter proposed some change in 2015, where
>> this kworker thread in replaced by a kthread with a RT priority if
>> the low_latency mode is selected.
>> See: https://www.spinics.net/lists/linux-serial/msg17782.html
>>
>> The follow-up discussion in this thread also proposes a solution that
>> allows low_latency ports to directly execute the worker.
>> As interrupts are already threaded in PREEMPT_RT, wouldn't that be a 
>> solution?
>
> The patches and discussions in that thread provide some good ground work
> for a real solution. Someone needs to take more time to work with the
> maintainers to get it mainline.

I am using the following patch.
Not sure if it is worth proposing it for mainline inclusion, though.
RFC:

commit ca633caa8a18e8043f7f59cf9b3b9cbe2097a5ee
Author: Esben Haabendal <eha@deif.com>
Date:   Fri Jun 1 13:03:41 2018 +0200

    tty: Re-introduce annoying historical pain in the butt
    
    Since a9c3f68f3cd8d55f809fbdb0c138ed061ea1bd25, use of UART for real-time
    applications has been problematic.
    
    When all CPU cores are running SCHED_FIFO tasks, tty buffers will be
    stalled, causing unbounded latency of UART RX.  For applications with
    real-time requirements to reaction UART RX, this is of-course unacceptable.
    
    This change reuses the old low_latency flag, but only respects it for
    drivers using threaded interrupt handler.  Applications caring about
    real-time requirements should do that anyway.
    
    Signed-off-by: Esben Haabendal <eha@deif.com>

diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
index f8eba1c5412f..eb9ad23341c1 100644
--- a/drivers/tty/tty_buffer.c
+++ b/drivers/tty/tty_buffer.c
@@ -399,6 +399,7 @@ EXPORT_SYMBOL(__tty_insert_flip_char);
 void tty_schedule_flip(struct tty_port *port)
 {
 	struct tty_bufhead *buf = &port->buf;
+	WARN_ON(port->low_latency);
 
 	/* paired w/ acquire in flush_to_ldisc(); ensures
 	 * flush_to_ldisc() sees buffer data.
@@ -408,6 +409,16 @@ void tty_schedule_flip(struct tty_port *port)
 }
 EXPORT_SYMBOL(tty_schedule_flip);
 
+static void flush_to_ldisc(struct work_struct *work);
+
+void tty_do_flip(struct tty_port *port)
+{
+	struct tty_bufhead *buf = &port->buf;
+	smp_store_release(&buf->tail->commit, buf->tail->used);
+	flush_to_ldisc(&buf->work);
+}
+EXPORT_SYMBOL(tty_do_flip);
+
 /**
  *	tty_prepare_flip_string		-	make room for characters
  *	@port: tty port
@@ -543,7 +554,18 @@ static void flush_to_ldisc(struct work_struct *work)
 
 void tty_flip_buffer_push(struct tty_port *port)
 {
-	tty_schedule_flip(port);
+	if (in_interrupt() || !port->low_latency)
+		/* Schedule buffer flip on workqueue if running in hardirq
+		   context, or if low_latency mode is not enabled.
+		*/
+		tty_schedule_flip(port);
+	else
+		/* Flip buffer immediately when when low_latency flag is set
+		   and running in threaded interrupt handler.  Without this,
+		   latency can increase dramatically when one or more
+		   SCHED_FIFO tasks are hogging the CPU(s).
+		*/
+		tty_do_flip(port);
 }
 EXPORT_SYMBOL(tty_flip_buffer_push);
 
diff --git a/include/linux/tty_flip.h b/include/linux/tty_flip.h
index 767f62086bd9..005443e83b2d 100644
--- a/include/linux/tty_flip.h
+++ b/include/linux/tty_flip.h
@@ -13,6 +13,7 @@ extern int tty_prepare_flip_string(struct tty_port *port,
 		unsigned char **chars, size_t size);
 extern void tty_flip_buffer_push(struct tty_port *port);
 void tty_schedule_flip(struct tty_port *port);
+void tty_do_flip(struct tty_port *port);
 int __tty_insert_flip_char(struct tty_port *port, unsigned char ch, char flag);
 
 static inline int tty_insert_flip_char(struct tty_port *port,

  reply	other threads:[~2018-07-09  9:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-06  8:51 tty latency and RT André Pribil
2018-07-06  9:16 ` John Ogness
2018-07-09  9:55   ` Esben Haabendal [this message]
2018-07-09 11:37     ` André Pribil
2018-07-11  8:09     ` Sebastian Andrzej Siewior
2018-07-13  8:33       ` Esben Haabendal
2018-07-18 16:49         ` Sebastian Andrzej Siewior

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=87pnzwag3n.fsf@gmail.com \
    --to=esben.haabendal@gmail.com \
    --cc=a.pribil@beck-ipc.com \
    --cc=john.ogness@linutronix.de \
    --cc=linux-rt-users@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).