public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Paul Fulghum <paulkf@microgate.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] TTY flip buffer SMP changes
Date: Thu, 07 Oct 2004 20:37:12 +0100	[thread overview]
Message-ID: <1097177830.31768.129.camel@localhost.localdomain> (raw)
In-Reply-To: <1097179099.1519.17.camel@deimos.microgate.com>

(Sorry not quoting but if you will use attachments 8))

Problem 1:
Agree. Using a common function is definitely needed, lets at least have
all the bugs in one place.

Problem 2:
Known. See the comment in the Documentation/tty.txt

Add:
Problem 3:
The buffering model is useless for virtualised devices or high speeds.


I've been pondering taking a very small performance hit to fix the
entire flipping mess (pardon the pun) and also to speed up the actual
common critical path (ppp) in the process.

Now that networking is not a kernel option it seems slightly dumb that
the tty layer doesn't just use the sk_buff model (probably not code).
kmalloc is very fast and it kills TTY_DONT_FLIP because every buffer is
owned by _one_ person at a time. (sk_buff's dont direclty fit too well
because we push both error and bits per byte and don't last time I
checked support recycling).

Another nice effect is simplifying the ldisc and driver level locking.
Drivers queue buffers, ldiscs eat buffers. If the driver queues a buffer
and there is temporarily no ldisc it does not get lost. 

This also saves us memory - most tty's spend most of their time idle.

Alan


  reply	other threads:[~2004-10-07 21:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-07 19:58 [RFC][PATCH] TTY flip buffer SMP changes Paul Fulghum
2004-10-07 19:37 ` Alan Cox [this message]
2004-10-08  6:26   ` Theodore Ts'o
2004-10-08 13:35     ` Paul Fulghum
2004-10-08 12:51       ` Alan Cox
2004-10-08 15:00         ` Theodore Ts'o
2004-10-09  1:42           ` Benjamin Herrenschmidt
2004-10-10  0:32             ` Alan Cox
2004-10-10  3:26               ` Benjamin Herrenschmidt
2004-10-10 12:49                 ` Maciej W. Rozycki

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=1097177830.31768.129.camel@localhost.localdomain \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulkf@microgate.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