lkml.org 
[lkml]   [1996]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 2.2.0 wishlist
Date
> Opps.  Maybe not into user-space!  But they do allow such memory to be
> passed all the way to the stream-head. OK, you can do similar (better?)
> with other methods, but I found using a release pointer for a data
> block flexible.

We aren't just worried about passing memory all the way to the stream head
we are actually at the point (especially on PC) where we are counting
references and locality of reference because even the L2 cache is a
performance issue.

> I found STREAMS a v. good service for what we were trying to do. If
> we were trying to pump data down an FDDI at 100Mbips, maybe we would
> have found the implementation/design lacking - I don't know.

I think so going by the experience of most others, including people who
worked their backsides off for years trying to write a good streams system.

> STREAMS allowed us to concentrate more on the ISDN protocol, rather than
> worrying about a lot of other details. We also got some good debug
> support from the service (a God send!). Not every line of code in
> the kernel needs to be optimised down to the last cycle (although in
> an idea world, it would), __sometimes__ a working implementation is
> better than no implementation (this last line sounds like flame bait,
> please note the underlining of 'sometimes').

Yes. ISDN is the classic example of where streams can make life far more
pleasant.

> > with fast streams has a stack where if all the modules arent real
> > streams but run in "cheat" mode as it were use different code paths.
> I though STREAMS managed to avoid a lot of memory copies, and uses
> caches of common objects/data sizes to speed up allocation. It is
> also possible to pass a message 'over' a 'layer'.
> Maybe I've misunderstood your point...

It's not copies, its passes over memory, number of references to memory and
their locality that is critical. The single pass copy/checksumming is a good
example. We copy the same amount of data but can do the checksum in the
instruction slots while the memory access are still taking effect. With
streams its hard to do that effectively. Our low level handlers also get
a fair chunk of performance by caching entire physical layer headers which
is about as blatant a violation of layering as you can get, but boy does it
pay off 8).

Linux is currently aimed to saturate 100baseT and 155Mbit ATM (thats
actually only just a bit over 100Mbit when you allow for its overhead).
Gigabit ethernet (1000baseT I guess) is on its way. Lots of other network
solutions are starting to appear in the 200-500Mbit range.

I don't think it will be that long (in terms of development cycles) that
people are looking on ISDN rather like an old 14.4 modem and wishing for a
T1/E1 instead.

Alan


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.030 / U:1.884 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site