>>>>> "Paul" == Paul Durrant <[EMAIL PROTECTED]> writes:
Paul> Actually, I often wondered whether the current mblk_t/dblk_t layout
Paul> hurts the OS anyway. I often wondered whether, in code scanning large
Paul> numbers of relatively small (sub-page) STREAMS messages it made sense
Paul> that the mblk_t and dblk_t were allocated from different pages
Paul> therefore forcing at least 2 TLB entries per message (although
Paul> messages allocated consecutively are quite likely to get mblk_t-s from
Paul> the same page if the cache is not too hot).
Paul> I once did some code to concatenate the mblk_t and dblk_t for small
Paul> messages but never had time to do any serious measurements on it. So,
Paul> if there's a move to extend messages for metadata then it may be a
Paul> good idea to address memory layout too.
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:
----------------------------------------------------------------------
There are several deficiencies in the current streams message allocator:
(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
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
since they aren't bound to their dblks.
----------------------------------------------------------------------
- Alexander Kolbasov
http://blogs.sun.com/akolb
Paul> Paul Durrant
Paul> http://www.linkedin.com/in/pdurrant
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
