Phil Harman wrote:
[snip]
> I'm currently working on some enhancements for libc's malloc() (and
> friends) which are primarily targeted at improving packing and thread
> scalability for small allocations (1-128 bytes).
BTW: It may be nice to think about adding more than one API for such
cases. For example libast (the base library for libshell/ksh93) uses
several own allocator APIs for different purposes (e.g. temporary
allocations are coming from a stack-like object which can use a
|mmap()|'ed file as backing store (which grows on demand)) which are FAR
more efficient than Solaris's |malloc()| and the design may be usefull
for general usage in Solaris, too.
Another idea may be to look at allocating all small temporary buffers
from the stack and only use |malloc()|&co. if the temporary allocation
exceeds a certain size (e.g. 32bytes for kernel threads and pagesize
(e.g. 4k for x86, 8k for SPARC) for userland applications.
Example (untested):
-- snip --
#include <stdlib.h>
#include <stdio.h>
#include <alloca.h>
#define TMPMEMALLOC_BORDERSIZE 32
#define TMPMEMALLOC(ptr, size) \
void *ptr = NULL, *ptr##malloced = NULL ; \
((size) > TMPMEMALLOC_BORDERSIZE)? \
(ptr = ptr##malloced = malloc(size)): \
(ptr = alloca(size))
#define TMPMEMFREE(ptr) \
if(ptr##malloced) \
free(ptr##malloced)
int main(int ac, char *av[])
{
/* do something */
TMPMEMALLOC(g1, 64);
/* do something */
TMPMEMFREE(g1);
/* do something */
return EXIT_SUCCESS;
}
-- snip --
For kernel code the |malloc()| needs to be replaced |kmem_alloc()| and
the code needs to make sure we don't grow beyond the stack - kernel
stacks in Solaris are very limited and cannot grow AFAIK but I think we
can safely use 256 bytes (total) without running into any problems (for
8k pages... in theory it may be nice to think about using 64k pages and
then bumping the total limit to 32k (which is enougth to hold at least
31 |PATH_MAX|-sized buffers... :-) )) - that's enougth to hold most
smaller path values without calling into the normal allocator at all
(which saves at least the function call overhead and in the worst case
lots of shuffeling to get some tiny piece of memory from the pool).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
