On Mon, Aug 22, 2005 at 12:38:01PM -0700, David McDaniel (damcdani) wrote: > Thanks Jonathon. Your description of the lifecycle of a buffer made > perfect sense. That kind of info would help if it got into the man page.
I'll work on getting the manpage updated. > I'm still not sure I understand the behavior of the destructor re when > and underwhat circumstances it might be used. The best I can imagine > would be the case (there may be other cases, of course) when cache "A" > has lots of free'd constructed objects and cache "B" has a need to > allocate some additional resource... The library maint thread might try > to steal some from A and calls the destructor to make them > unconstructed. Are there better examples? That's pretty much the idea. Another example is when the "guards" debugging option is enabled; in that case, we immediately destruct the buffer when it is freed, and write 0xdeadbeef over it. When the buffer is next allocated, we verify the 0xdeadbeef pattern, overwrite it with 0xbaddcafe, call the constructor, and return it. > In any case, I have a couple of followup questions. > -- Regarding the reclaim function, as I understand it, the reclaim > function is not required to succeed or fail in any particular way. Thus, > if I wanted to I could highjack it for some simple reporting purpose > like printing a trace of the fact that the pool in question had reached > the point of needing more memory. Correct? It's actually (for the moment at least) more of a global notification; all the reclaim callbacks are called when umem is trying to prune things. > -- Is there any straightforward way to cap the size of a cache? Unless > I've missed something subtle I don't see any way to set an upper limit. > Similarly I don't see a way to "hint" at the minimum number of buffers > to initially create. No; buffers are created on demand, and there's no way to cap them. > -- Lastly, is there any means to observe the state of a cache, ie to > determine the current number of unconstructed/constructed/allocated > buffers? There's no programmatic interface to do so, but the mdb(1) dcmds can give some of that information (allocated/total; unconstructed v.s. constructed is not called out). Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
