From owner-freebsd-hackers  Tue Dec  3 04:25:49 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id EAA08227
          for hackers-outgoing; Tue, 3 Dec 1996 04:25:49 -0800 (PST)
Received: from cheops.anu.edu.au (avalon@cheops.anu.edu.au [150.203.149.24])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id EAA08221;
          Tue, 3 Dec 1996 04:25:41 -0800 (PST)
Message-Id: <199612031225.EAA08221@freefall.freebsd.org>
Received: by cheops.anu.edu.au
	(1.37.109.16/16.2) id AA283075983; Tue, 3 Dec 1996 23:26:23 +1100
From: Darren Reed <avalon@coombs.anu.edu.au>
Subject: Re: TCP/IP bandwidth bragging
To: davem@jenolan.rutgers.edu (David S. Miller)
Date: Tue, 3 Dec 1996 23:26:23 +1100 (EDT)
Cc: avalon@coombs.anu.edu.au, dyson@freebsd.org, dennis@etinc.com,
        kpneal@pobox.com, hackers@freebsd.org, sparclinux@vger.rutgers.edu
In-Reply-To: <199612030410.XAA18471@jenolan.caipgeneral> from "David S. Miller" at Dec 2, 96 11:10:51 pm
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

In some mail from David S. Miller, sie said:
> 
>    Tell me, does Linux implement STREAMS in the kernel with a properly
>    stacked network implementation, using DLPI and TLPI with fine grain
>    mutexes and locks ?
> 
> Oh yes, then we'll have real performance.  Take a look at how many
> fastpaths and shortcuts the Solaris folks have to do to overcome the
> performance problems assosciated with streams.  The Solaris
> performance people are constantly breaking their necks to find new
> ways to overcome these issues.  If Ritchie couldn't get it right,
> perhaps this is good enough cause that it isn't such a hot idea, and
> that the implementation needs to be done differently (see below) or
> the entire idea trashed.
> 
> Streams can be done at the user level with minimal kernel support.
> 
> The only reason it is completely in the kernel in most commercial
> systems is that someone let it in there in the first place.  It is
> very hard to "take out" something like that once it is in, especially
> in a commercial source tree.
> 
> Fine grained mutexes and locks, yes that will indeed get you scaling
> better than a master lock implementation (which is what Linux has at
> the moment).  But it is not a reasonable way to implement scalable SMP
> systems.
> 
> For how I think it should be done, investigate the numerous papers
> available on non-blocking synchronization and (harder to find) self
> locking data structures.

Right.  So comparing Linux performance to Solaris is like comparing apples
and oranges.

Comparing NetBSD/OpenBSD/FreeBSD performance would be more meaningful than
comparing Linux vs any of those three.

Darren