From: Linus Torvalds <torvalds@linux-foundation.org>
To: Oleksij Rempel <o.rempel@pengutronix.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>,
Pengutronix Kernel Team <kernel@pengutronix.de>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v1 3/3] drivers/tty: increase priority for tty_buffer_worker
Date: Mon, 28 Jan 2019 12:13:59 -0800 [thread overview]
Message-ID: <CAHk-=whe72pccEAdQsp+UpjzKxXzsHbkiyaXbhG1UHnNg6uw1g@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=wjOMvFBxmBSBZPZEwSyU96L5V8Qhi6bXLqzV4Sdsb2HAg@mail.gmail.com>
On Mon, Jan 28, 2019 at 12:03 PM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> That's harder to do for reads - because incoming characters happen in
> interrupt context, but shouldn't be all that hard to do for writes.
Side note: the reason I mention this part is that "harder" may not
mean "impossible".
In particular, I wonder if we could do the tty buffer flipping in the
reader context too. Currently, what happens is that when we receive
characters, we schedule things for flipping with the workqueues. *BUT*
we could also just wake up any pending readers directly, and maybe
have the *readers* do the flip if they wake up before the workqueue.
And that would allow you to do real-time serial work simply by marking
the process *you* care about as RT, and not worry so much about the
workqueue threads at all. The workqueue threads would be fallbacks for
when there isn't an active reader at all.
I dunno. A bit handwavy, I know, but it sounds like if you care about
the read latency, that would be a better model entirely (skipping the
technically unnecessary kernel workqueue entirely).
Linus
next prev parent reply other threads:[~2019-01-28 20:14 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-10 10:12 [PATCH v1 0/3] reduce tty latency Oleksij Rempel
2019-01-10 10:12 ` [PATCH v1 1/3] drivers/tty: refactor functions for flushing/queuing work Oleksij Rempel
2019-03-11 8:16 ` Alexander Sverdlin
2019-01-10 10:12 ` [PATCH v1 2/3] drivers/tty: convert tty_port to use kthread_worker Oleksij Rempel
2019-03-11 8:23 ` Alexander Sverdlin
2019-01-10 10:12 ` [PATCH v1 3/3] drivers/tty: increase priority for tty_buffer_worker Oleksij Rempel
2019-01-10 12:54 ` Linus Torvalds
2019-01-10 15:19 ` Oleksij Rempel
2019-01-10 16:30 ` Greg Kroah-Hartman
2019-01-28 8:05 ` Oleksij Rempel
2019-01-28 8:23 ` Greg Kroah-Hartman
2019-01-28 9:22 ` Oleksij Rempel
2019-01-28 20:03 ` Linus Torvalds
2019-01-28 20:13 ` Linus Torvalds [this message]
2019-01-10 16:59 ` Linus Torvalds
2019-03-11 8:24 ` Alexander Sverdlin
2019-01-10 13:51 ` [PATCH v1 0/3] reduce tty latency Greg Kroah-Hartman
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='CAHk-=whe72pccEAdQsp+UpjzKxXzsHbkiyaXbhG1UHnNg6uw1g@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=jslaby@suse.com \
--cc=kernel@pengutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=o.rempel@pengutronix.de \
/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).