Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190110101232.9398-1-o.rempel@pengutronix.de>
 <20190110101232.9398-4-o.rempel@pengutronix.de> <CAADWXX_G7X6QkNuqnpMyr+MGP+nUhqPaifJrfC=m57mhJu2jdg@mail.gmail.com>
 <20190110151953.qpat4t7lat6plfk6@pengutronix.de> <20190110163030.GB19693@kroah.com>
 <7a593f3b-0019-c30f-30e8-34eae7b96cf0@pengutronix.de> <20190128082313.GA15182@kroah.com>
 <dedfa895-ae7e-9a64-9e89-055ca85cf2e3@pengutronix.de> <CAHk-=wjOMvFBxmBSBZPZEwSyU96L5V8Qhi6bXLqzV4Sdsb2HAg@mail.gmail.com>
In-Reply-To: <CAHk-=wjOMvFBxmBSBZPZEwSyU96L5V8Qhi6bXLqzV4Sdsb2HAg@mail.gmail.com>
From:   Linus Torvalds <torvalds@linux-foundation.org>
Date:   Mon, 28 Jan 2019 12:13:59 -0800
Message-ID: <CAHk-=whe72pccEAdQsp+UpjzKxXzsHbkiyaXbhG1UHnNg6uw1g@mail.gmail.com>
Subject: Re: [PATCH v1 3/3] drivers/tty: increase priority for tty_buffer_worker
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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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