Re: new lwbuf api and mpsafe sf_bufs

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
:> =A0 =A0The sfbufs are statically allocated and thus have scaling issues
:> =A0 =A0(e.g. the example Samuel gave on IRC is when one running many para=
:llel
:> =A0 =A0sendfile()'s). =A0 I would like to see the SFBUF code use a more
:> =A0 =A0dynamic model and a sysctl which sets the maximum number of *exces=
:s*
:> =A0 =A0sfbufs instead of the maximum number of sfbufs.
:
:I thought I would ask this before laying down any code, you (Dillon)
:mentioned putting this into an rbtree previously as opposed to the
:existing hash.  Even if we do a variable hash (maybe just one that
:grows, not shrinks?) amortized costs should be lower than an rbtree.
:Is there any rationale as to why an rbtree would be preferrable in
:this case apart from simply being simpler in implementation compared
:to a variable hash?
:
:Sam

    No, not particularly.  A hash will probably work just as well, it just
    doesn't scale.  I've found that even though binary trees have longer
    access times they also require less code maintainance and deal with
    scaling cases better.

    Hashes do have one undesireable effect.  If the hash is large enough
    then accesses which do not translate to any sort of locality of reference
    within the hash table can really mess up the cpu's L1 and L2 cache.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>