Re: [networking-discuss] mblk extensions

[Paul Durrant]

On 18 Mar 2006, at 01:41, Alexander Kolbasov wrote:

It was like that before a new STREAMS message allocator was introduced in 1996

(as bug 1241255). The old code had to deal with issues introduced by
dupb/pullupmsg/freeb. Here is a comment from the bug report:

Interesting. I was not aware of the previous scheme, but then I joined Sun late in 1996 as it happens :-)

----------------------------------------------------------------------


(1) Maintainability.  The current mblk/dblk/data triples create a
    maintenance nightmare because of the semantics of pullupmsg()
    and dupb().  As a result, pullupmsg() and freeb() -- both of
    which are conceptually trivial -- are among the most subtle,
    awkward, complex and unmaintainable routines in the system.
    We have had literally dozens of escalations due to memory
    leaks and data corruption originating in these routines.

(2) Performance.  allocb()/freeb() performance suffers from the
    complexity of freeb(), which is due to mblk/dblk/data triples.

And


  since they aren't bound to their dblks.
----------------------------------------------------------------------

There are several deficiencies in the current streams message allocator: Rewrite the streams message allocator so that mblks are allocated separately from the dblk/data they describe. This makes freeb() and pullupmsg() trivial. freeb() no longer has to worry about whether an mblk describes the adjoining dblk or some other dblk, and pullupmsg() can simply swap the leading mblks

  Paul

--
Paul Durrant

Given the lack of TLB and cache localility though it would seem that the complexity of the triples may be worthwhile. When I experimentally re-wrote the code I actually adopted a hybrid scheme of triples and a separate mblk cache to cover dupb(). The code did not seem overly complex. I do recall some subtleties in implementing freeb() but the code did not get so horrendous that I gave up on my experiment :-) Alas the code was lost with the closure of UK R&D operations, otherwise I would send it to you.

PGP.sig
Description: This is a digitally signed message part

_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org