Subject: Re: ccd
To: Jason Thorpe <firstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 06/13/1997 16:47:35
>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
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?