On 2011-08-19, Alan Cox <alan@xxxxxxxxxxxxxxxxxxx> wrote:
>> I don't understand why the low_latency flag even exists when setting
>> it apparently breaks most all of the serial drivers.
>
> Mostly history. I'd not realised random users could fiddle with it - they
> shouldn't be able to do that so that wants fixing.
>
> Historically it made sense as with a 100Hz clock some algorithms with
> drivers that delayed stuff a lot got really slow (eg non windowed
> versions of firmware download protocols, kermit, xmodem etc)
I know why it used to be there, and "back in the day" setting it made
a very noticable difference in the latency on the receive data path.
In some situations, setting the low_latency flag could increase by a a
factor of 10 the number of command/reply transactions you could do per
second (particularly at high baud rates and commands/repsonses are
only a couple bytes).
> Nowdays the kernel is a bit more sophisticated and we should possibly
> re-arrange it so that it selects different workqueues or similar -
> low_latency meaning 'use a private hard rt work queue' perhaps.
>
> Or indeed possibly making ttys use threaded IRQs
For most of the drivers I'm maintaining, I've decided I'm going to
have to force low_latency = 0. There is one driver that has one mode
where the receive data is handled in a non-atomic context, so that one
can still honor the low_latency flag, but the rest will have to force
it to 0.
[Why this only became a problem recently, I don't know.]
--
Grant Edwards grant.b.edwards Yow! Am I in Milwaukee?
at
gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
