>Now, looking at this info on my source code/build server here at work:
>
>Statistics for ccd0:
>        freelist count: 16
>        freelist hiwater: 16
>        freelist misses: 28701
>        ccdbuf allocations: 194898
>
>I think I might bump the CCDNBUF value the next time I build a kernel
>for this box :-)

I'm sure this works well. But is there some reason *not* to
dynamically tune the private buffer pool used for ccds?

Add a (settable) desired hit ratio. If you miss more than the desired
hit ratio allows allows, malloc() as many buffers again as ccd had
before.

This could be done pretty cheaply; ccd alredy counts misses, it'd just
have to check every N misses (or when misses mod (N*nccdbuf)==0) to
see if the desired miss rate was being exceeded.  If the miss rate is
being exceeded, double the number of buffers.

With a ceiling (allocate no more than, say, .5% of the max buffer pool
size to private ccd buffers), this should be pretty safe.

You could gold-plate this and do something like the TCP rtt estimator,
in order to discover when CCD activity has dropped significantly and
private ccd buffers are over-allocated. But why bother, if we assume
there're only a few ccds?

Or we could add CCDMAXBUF as a maximum threshold, which gives the same
semantics as now, but with lazy allocation of that many buffers.

I dunno.... I'd have thought static allocation of a private cache of
buffers was fine. But if one user is having enough problems this to
ask about it on current-users, then maybe it's a problem.  My silly
little hack would mostly fix it. And it would easily allow changes to
the ccdbuf-cache parameters via sysctl, instead of rebooting.  

Jason, do you think it's worth the code growth?