On Fri, 13 Jun 1997 01:38:51 -0500 (CDT) 
 "Tom T. Thai" <tomthai@future.net> wrote:

 > I have no idea how interpret this from my ccd
 > 
 > # ccdconfig -s
 > Statistics for ccd0:
 >         freelist count: 15
 >         freelist hiwater: 16
 >         freelist misses: 328
 >         ccdbuf allocations: 60132

Ok, what that is telling you:

	You have performed 60,132 discrete component transactions.  Each
	of those required allocation of a ccdbuf, which describes the
	component i/o transaction.

	Of those 60,132 allocations, 328 of them resulted in calls to
	malloc().  The remaining 59,804 were allocated from a ccdbuf
	freelist, which is much faster than calling malloc().

...in other words, the component buffer header freelist is being fairly
effective in your case.  The freelist count tells you there are currently
15 ccdbufs on the freelist.  The hiwater tells you that there will be,
at most, 16 on the freelist.  In other words, if a ccdbuf was malloc'd,
and there are already 16 ccdbufs on the freelist, it will be free'd,
rather than put on the freelist.

If you find your freelist misses are high, you can set the kernel config
option "CCDNBUF" to some value.  That value indicates the number of
ccdbuf's that will be allocated per component.  The default is 8 (which,
in your case, means you have 2 components, since your hiwater is 16).

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 :-)

This particular change was driven by kernel profile information provided
by Thor Simon.  He noted that a large amount of time was being spent
in the ccdbuffer() routine, which is what generates a ccd componet i/o
request.  The vast majority of the time in that function was spent
in malloc().  By adding the ccdbuf freelist, ccdbuffer() became a much
faster routine.  You'll note where ccdbuffer() is called: in a loop in
ccdstart(), which fires off the component i/o requests.  It's sort of
a "critical path".  In one of my tests, writing a large (2G) file to
the file system, I noticed a savings of some large-ish number of
wall-clock seconds after I made the freelist change.  (Sorry, I don't
have the numbers anymore.)

Is that the answer you were looking for?  :-)

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                               Home: 408.866.1912
NAS: M/S 258-6                                          Work: 415.604.0935
Moffett Field, CA 94035                                Pager: 415.428.6939