public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Stuart MacDonald" <stuartm@connecttech.com>
To: "James R Bruce" <bruce+@andrew.cmu.edu>, <linux-kernel@vger.kernel.org>
Cc: <tytso@mit.edu>
Subject: Re: serial port O_SYNC functionality in 2.4.5
Date: Tue, 3 Jul 2001 16:42:00 -0400	[thread overview]
Message-ID: <040a01c10400$9c6a2e40$294b82ce@connecttech.com> (raw)
In-Reply-To: <IvEWK2Rz00018DeGw=@andrew.cmu.edu>

From: "James R Bruce" <bruce+@andrew.cmu.edu>
> The overall size of the circular buffer would have to be decreased
> too, but that's more of a hack to fix it now; Which I guess is what it
> comes to.

I see what you're saying; AFAIUnderstand, the low latency patches
bypass the circular buffer. Or make it size one.

> This is not really a problem; 16 bytes of hardware buffering I can
> live with; at 19200 baud this is 7ms of lag.  The 4096 byte software
> buffer causes 1706ms of lag; That *is* a problem.  It's a bit like the
> difference between a hard disk drive's local buffer and the OS's (much
> larger) buffering.  O_SYNC on a disk garuntees that the output has
> been flushed to the disk, but maybe not the physical medium.  On a
> serial port, similar functionality would be to have output to pushed
> to the UART, but maybe not yet over the actual port.

Gotchya.

> The manpage seems to imply this would work, but it doesn't seem to
> affect the software buffering at all (I tried this yesterday).  AFAICT
> from looking at the driver, the low_latency mode only applies to
> reading, not writing: tty_flip_buffer_push(tty) is the only place the
> latency flag is ever checked, and that is only called in receive_chars
> in serial.c.  The application that caused this doesn't get any serial
> input whatsoever, so that won't (or at least shouldn't) get called.

Hm. I haven't looked at the low_latency stuff, I was just repeating what
I'd heard...

> I changed WAKEUP_CHARS to 1 rather than 256 (0 would cause processes
> to hang forever, btw), and SERIAL_XMIT_SIZE to 16 rather than
> PAGE_SIZE.  A proper solution would make this conditional on O_SYNC or
> low_latency or even a kernel option.  Suggestions?

If you check the code, the circ buffer will never have a count < 0, so the
hang
is predictible; tty is never called for more tx chars.

I'd say it should be part of low_latency. Although it's probably best to
have
rx low_latency and tx low_latency separately configurable. Honouring O_SYNC
might not be a bad idea as well.

Whatever option probably should make SERIAL_XMIT_SIZE == WAKEUP_CHARS;
SERIAL needs to be a power of two, so 2, 4, 8 or 16 would be good choices.
Probably should be similar to the rx low_latency.

Best way to get this in the serial driver is to do some patches for it
and send them to Ted. :-)

..Stu



  reply	other threads:[~2001-07-03 20:39 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-03 20:05 serial port O_SYNC functionality in 2.4.5 James R Bruce
2001-07-03 20:42 ` Stuart MacDonald [this message]
2001-07-03 21:09   ` Russell King
  -- strict thread matches above, loose matches on Subject: below --
2001-07-03  8:25 James R Bruce

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='040a01c10400$9c6a2e40$294b82ce@connecttech.com' \
    --to=stuartm@connecttech.com \
    --cc=bruce+@andrew.cmu.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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