mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Peter Hurley <peter@hurleysoftware.com>
Cc: Grant Edwards <grant.b.edwards@gmail.com>,
	linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-rt-users@vger.kernel.org
Subject: Re: locking changes in tty broke low latency feature
Date: Wed, 19 Feb 2014 21:42:42 +0000	[thread overview]
Message-ID: <20140219214242.406e705b@alan.etchedpixels.co.uk> (raw)
In-Reply-To: <53051276.2070601@hurleysoftware.com>

> > Because low latency is about *turn around* time. There are plenty of
> > protocols that can flow control, do flow control and want low latency
> > because they are not windowed. It's not mutually exclusive by any means.
> 
> But if it's all about turn around time, how can the situation devolve to
> needing throttling in the first place?  For N_TTY, throttling only happens
> when the read queue is close to overflow (only 128 bytes left in 4k buffer).

Because if we are on the uplink end of a dumb protocol then our flow ends
up as

< 4K in
		read
rest of block
		read
		block complete
		write Y

until at some point sods law decrees that we do a big load of disk
writes, an SMM event steals the processor, firefox garbage collects or
somesuch and we go

4K in
		throttle
		flow control


It only has to happen *once*, not every time to screw stuff up.

> If the reader isn't pulling _all_ the data out the instant it's woken,
> trying to trim off one worker wakeup (by processing input at interrupt time)
> is pointless.

No - because of the statistical corner cases. The standard Linux is not
remotely hard real time, and even if it were most of the tools involved
are not.

> > Low latency goes back to the days of flip buffers, bottom halves an a
> > 100Hz clock. There are certainly better ways to do it now if its needed.
> 
> Still, as you've pointed out a couple of times, maybe there's a limited
> fastpath that's easy and simple. That's why I was asking about throttling
> because it's evaluated even for raw mode.

Even if there isn't the goal of low latency was always 'get stuff to
happen soon' not 'get stuff to happen in the IRQ handler' If you have the
tty processing happening immediately after the IRQ returns when
low_latency is set I'm sure the numbers will be just fine and as good as
historically.

Whether you can always do that I guess depends what happens on really
slow boxes if you don't do any deferral - eg on Geert's Amiga.

Flow control even in raw mode is expected Unix behaviour. However do we
ever need to evaluate it if the tty termios has IXON and CRTSCTS clear ?

Alan

  reply	other threads:[~2014-02-19 21:43 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-18  9:38 Stanislaw Gruszka
2014-02-18  9:57 ` One Thousand Gnomes
2014-02-18 22:12 ` Peter Hurley
2014-02-19 13:03   ` Stanislaw Gruszka
     [not found]     ` <le2nmd$p1$1@ger.gmane.org>
2014-02-19 17:38       ` Peter Hurley
2014-02-19 18:12         ` Grant Edwards
2014-02-19 18:42           ` Peter Hurley
2014-02-19 19:17         ` One Thousand Gnomes
2014-02-19 20:22           ` Peter Hurley
2014-02-19 21:42             ` One Thousand Gnomes [this message]
2014-02-20  2:19               ` Peter Hurley
2014-02-21 15:39                 ` One Thousand Gnomes
2014-02-21 15:58                   ` Peter Hurley
2014-02-21 16:31                     ` Grant Edwards
2014-02-19 23:06     ` Hal Murray
2014-02-19 23:35       ` One Thousand Gnomes
2014-02-20  2:55       ` Peter Hurley
2014-02-20  4:16         ` Greg KH
2014-02-20 18:16         ` Peter Hurley
2014-02-20 19:33           ` Grant Edwards
2014-02-20 22:06             ` Peter Hurley
2014-02-23 22:33           ` Thomas Gleixner
2014-02-24  0:23             ` Peter Hurley
2014-02-24 13:23             ` One Thousand Gnomes
2014-02-20 21:55         ` Hal Murray
2014-02-20 22:14           ` Grant Edwards
2014-02-21 15:43             ` One Thousand Gnomes

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=20140219214242.406e705b@alan.etchedpixels.co.uk \
    --to=gnomes@lxorguk.ukuu.org.uk \
    --cc=grant.b.edwards@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=linux-serial@vger.kernel.org \
    --cc=peter@hurleysoftware.com \
    /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

all inboxes | Powered by JetHome®