Date: Tue, 3 Dec 1996 23:26:23 +1100 (EDT) From: Darren Reed <avalon@coombs.anu.edu.au> To: davem@jenolan.rutgers.edu (David S. Miller) Cc: avalon@coombs.anu.edu.au, dyson@freebsd.org, dennis@etinc.com, kpneal@pobox.com, hackers@freebsd.org, sparclinux@vger.rutgers.edu Subject: Re: TCP/IP bandwidth bragging Message-ID: <199612031225.EAA08221@freefall.freebsd.org> In-Reply-To: <199612030410.XAA18471@jenolan.caipgeneral> from "David S. Miller" at Dec 2, 96 11:10:51 pm
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612031225.EAA08221>