linux-kernel - Re: [PATCH v1 3/3] drivers/tty: increase priority for tty_buffer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wjOMvFBxmBSBZPZEwSyU96L5V8Qhi6bXLqzV4Sdsb2HAg@mail.gmail.com>
Date:   Mon, 28 Jan 2019 12:03:21 -0800
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Oleksij Rempel <o.rempel@...gutronix.de>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Pengutronix Kernel Team <kernel@...gutronix.de>,
        lkml <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 3/3] drivers/tty: increase priority for tty_buffer_worker

On Mon, Jan 28, 2019 at 1:22 AM Oleksij Rempel <o.rempel@...gutronix.de> wrote:
>
> Yes, I tested it with different linux-rt version with mostly similar results:

Hmm. It strikes me that you use very carefully timed serial *writes*
to control the laser cutter, but the flip buffer handling is mostly a
latency issue on the *read* side, isn't it?

Are you sure you are testing the right thing? Because your loopback
test is testing the latency not of writes, but of writes _and_ reads.

I'm wondering if we could/should try to simply avoid the workqueue
entirely if we could do the work in process context.

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.

In fact, I thought we already did writes without any tty buffer
flipping at all, and that your patch series shouldn't actually affect
any write latency, but I've happily not had to work much with the
tty/serial layer in years..

Do you actually have read latency issues? Or is this whole series
perhaps an artifical effect of the benchmark you use?

                Linus