Hmm... a quick look through the slab allocator code (mm/slab.c) shows
that kmalloc keeps cached pools of chunks with sizes of powers-of-2,
starting with 32 (64 on 64-bit architectures). If we allocate the
list elements on-the-fly and including the string as a static piece
(the old "char name[0]" as last element trick), then space shouldn't
be too much of a problem.
A greater concern is latency: __kmem_cache_{alloc,free} are the
underlying routines, and are protected by spinlocks. Does anyone out
there have hard numbers (cycle counts, "10000 iterations took X
milliseconds", etc) on these functions?
Adam
-- You crucify all honesty \\Adam D. Bradley artdodge@cs.bu.edu No signs you see do you believe \\Boston University Computer Science And all your words just twist and turn\\ Grad Student and Linux Hacker Reviving just to crash and burn \\ <>< ---------> Why can't you listen as love screams everywhere? <--------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu