All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Paul Fulghum <paulkf@microgate.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] TTY flip buffer SMP changes
Date: Fri, 8 Oct 2004 02:26:50 -0400	[thread overview]
Message-ID: <20041008062650.GC2745@thunk.org> (raw)
In-Reply-To: <1097177830.31768.129.camel@localhost.localdomain>

On Thu, Oct 07, 2004 at 08:37:12PM +0100, Alan Cox wrote:
> 
> 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).

Suggestion: use two skbuff's for the data bytes and the error flags,
and make the error skbufs be optional --- sometimes the line discpline
won't care about the error bytes at all (example: raw mode).

Even if kmalloc() isn't as fast using two ring buffers which we flip
back and forth, CPU's have gotten a lot faster since when I
implemented the flip buffers some 12 years ago (i.e., 8 Moore law's
doublings ago).  If you nuke flip buffers, I'm not going to take it
personally.  :-)

> 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. 

Agreed.

						- Ted

  reply	other threads:[~2004-10-08  6:28 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
2004-10-08  6:26   ` Theodore Ts'o [this message]
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=20041008062650.GC2745@thunk.org \
    --to=tytso@mit.edu \
    --cc=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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.