On Sun, 21 Aug 2005, Jonathan Adams wrote:
.... snip ....
> Not a problem; if you have any suggestions on how to make the manpage more
> clear, I'll be happy to get it changed.
Hi Jonathan,
What's not clear to me is when to use or avoid using it. I understand the
concepts of the slab allocator and have read the code. And recently I took
a look at modhash.c in src/uts/common/os which uses the kmem_cache_alloc
rather than umem_cache_alloc - but it appears to be a variant on the same
underlying implementation and a good example of using these interfaces.
So here's a question: If I'm allocating small sized structures, like
pointers or small linked list structures (^prev, ^next, ^data), that don't
need any (slab) constructor or destructor functions, should I use
umem_cache_alloc or just use libumem malloc/free?
More about the application: It's a messaging application where user
generated messages are stored in a hash table with 600011 entries. Each
hash table bucket stores a double linked list of messages associated with a
single subscriber. New messages are added to the front of the linked list.
When a new message arrives, the linked lists are scanned to determine if
this is a duplicate message in the last 5 minutes (time_t timestamps are
part of the data associated with a message that is stored which is about
104 bytes in size). The lists grow to include 24 hours of messages to
provide stats, rate limiting etc. When the system is less busy, the lists
will be scanned and data older than 24 hours will be removed. So, upon
startup, the data structures will grow for the first 24 hours and may not
be pruned until the early hours of the AM when the system is idle. This
app is currently load balanced on 6 servers and the average # of entries in
the system, after been pruned would be around 50k, and before about 150k.
We've working on consolidating the app to a single server - so the code is
being rewritten [1] and efficiency is important. Currently it's a single
threaded app and will probably remain single threaded. The original code
runs on Solaris 8 and I'm considering taking advantage of every Solaris 10
feature that would add value - like libumem.
So there are many different dynamic data structures associated with the
app:
1) the hash table itself with 600k slots
2) the hash buckets (linked list with generic pdata pointer)
3) the linked list of messages with a fixed structure size and a pointer to
the actual message packet.
4) the message packet. A structure of 104 bytes with many pointers. [2]
5) the message text itself - referenced by a pointer in 4) and anything
from a few bytes to ~ 500 bytes with ~ 70 bytes being the average size.
I'm not trying (really!) to turn this into an app specific question - but
in discussing when using the slab allocator would/would-not make sense.
The unusual aspect of this app, is the fact that the memory structures grow
for the first 24 hours and are pruned infrequently.[3]
Notes:
[1] Bad Word alert!
[2] The linked list header has a ptr to a list member destructor function
and an overall list destructor.
[3] In case it's not obvious, the app has to run 7x24x365.
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134
OpenSolaris Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
