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'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?
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? -- 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. -- Lastly, is there any means to observe the state of a cache, ie to determine the current number of unconstructed/constructed/allocated buffers? Thanks -d > -----Original Message----- > From: Jonathan Adams [mailto:[EMAIL PROTECTED] > Sent: Monday, August 22, 2005 1:37 AM > To: David McDaniel (damcdani) > Cc: opensolaris-discuss@opensolaris.org > Subject: Re: [osol-discuss] Obscure umem semantics > > On Wed, Aug 17, 2005 at 06:46:40PM -0700, David McDaniel wrote: > > This might be better suited to another board, but if so I dont know > > which one. In any case the dialog might be valuable to the > community > > at large. To wit: > > I dont fully grasp the semantics of umem_cache_alloc, et al. Some > > use cases or examples would really help. A few of the obscure (to > > me) points follow. Any clarification is appreciated. > > > > - The reclaim callback seems only partially defined to me. Here is > > the clip from the man page: > > The reclaim callback is called when the umem function is > requesting > > more memory from the operating system. This callback can be > used by > > clients who retain objects longer than they are strictly > needed (for > > example, caching non-active state). A typical reclaim > callback might > > return to the cache ten per cent of the unneeded buffers. > > > > So, if the reclaim callback is called, does it happen before or > > after the call to the OS (sbrk?) to get more memory? And > if it does > > indeed "reclaim" something is the call to the OS avoided? > And if it > > does not succeed (how would I know since it returns void) does the > > OS get called? > > It will be called at an unspecified time with umem feels more > memory is appropriate. When exactly that is is not > documented or guaranteed. > > Typically this is asynchronous to any allocation failure. > > > As far as I can tell, the idea is that I (in the app) would have > > a secret stash of objects that have not been umem_cache_free()'d > > hidden away somewhere and if so the reclaim callback might > > interatively free them in lieu of (or in addition to?) a > call to the > > OS to allocate more buffers. Is that even remotely the idea? > > Yes; for example, in the kernel the UFS inode cache frees > some when this callback is used. > > > - Constructor/destructor call sequence. Here is the > really confusing > > statement re umem_cache_alloc() : > > > > ...The object cache was able to use a previously freed > buffer. If the > > cache was created with a constructor, the object is > returned unchanged > > from when it was freed > > > So, does this suggest that the destructor does not always get > > called? > > Yes; it will not always be immediately called after > umem_cache_free(). > > > Or if it does that there is some signature that denotes > whether is has > > been changed or not? > > No externally visible signature exists. > > > And/or that of there is no > > destructor that the constructor will be called exactly once > for each > > buffer, but if a destructor exists the constructor will be > called for > > each allocation? > > No; The existence of the destructor has no effect on object > construction. > > The way it works is a buffer is in one of three states: > > unconstructed > constructed > allocated > > The constructor moves a buffer from unconstructed to > constructed, and the destructor (if one is specified) moves > it back. umem_cache_alloc() moves a buffer from constructed > to allocated, and umem_cache_free() moves a buffer from > allocated back to constructed. > > The details of when a umem choses to move an object back to > unconstructed depend on what debugging options are in place, > and the memory usage of the application. In any case, the > destructor is called before the memory is re-used for any > other purpose. > > So when you allocate a buffer from a cache which has a > constructor, it has > either: > had the constructor applied, or > was previously freed with umem_cache_free() > > and in either case, umem will not touch the buffer between > the previous state and the allocation; the upshut is that you > need to make sure that buffers freed with umem_cache_free() > are in a state where they can be used after an allocation. > > Does that make sense? > > > Sorry if this is an overly long post, but these umem > facilities seem > > pretty powerfull of used correctly. As far as I can tell > right now, it > > is unclear exactly how to do so. > > Not a problem; if you have any suggestions on how to make > the manpage more clear, I'll be happy to get it changed. > > Cheers, > - jonathan > > -- > Jonathan Adams, Solaris Kernel Development > _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
