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
[EMAIL PROTECTED]
