Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S267968AbUJHG2k (ORCPT ); Fri, 8 Oct 2004 02:28:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S268029AbUJHG2k (ORCPT ); Fri, 8 Oct 2004 02:28:40 -0400 Received: from [69.25.196.29] ([69.25.196.29]:26780 "EHLO thunker.thunk.org") by vger.kernel.org with ESMTP id S267968AbUJHG2i (ORCPT ); Fri, 8 Oct 2004 02:28:38 -0400 Date: Fri, 8 Oct 2004 02:26:50 -0400 From: "Theodore Ts'o" To: Alan Cox Cc: Paul Fulghum , Linux Kernel Mailing List Subject: Re: [RFC][PATCH] TTY flip buffer SMP changes Message-ID: <20041008062650.GC2745@thunk.org> Mail-Followup-To: Theodore Ts'o , Alan Cox , Paul Fulghum , Linux Kernel Mailing List References: <1097179099.1519.17.camel@deimos.microgate.com> <1097177830.31768.129.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1097177830.31768.129.camel@localhost.localdomain> User-Agent: Mutt/1.5.6+20040907i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1411 Lines: 31 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/