Hi!
----
I've been looking for a way to reduce the startup time of libast-based
applications. I've got some benchmarking feedback back from Sun staff
which indicates that the runtime of a simple piece of code like:
-- snip --
int main(int ac, char *av[])
{
return b_mkdir(ac, av, NULL);
}
-- snip --
... needs approximately _twice_ the execution time of the current native
command (see
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/mkdir/mkdir.c).
After some digging I found this:
The number of lines returned by /usr/bin/truss is ~~47 lines for the old
code vs. ~~62 lines for the new code. The difference can be broken down
to this:
1. One extra call to |sysconfig(_CONFIG_PAGESIZE)|
2. Four extra calls to |brk()|
3. Ten various calls to load libast+libcmd
[3] isn't really fixable
[1] and [2] can be eliminated by the following patch and setting
|_AST_PAGESIZE| to 65536 on Solaris/SPARC:
-- snip --
Index: common/vmalloc/vmhdr.h
===================================================================
--- common/vmalloc/vmhdr.h (revision 1620)
+++ common/vmalloc/vmhdr.h (working copy)
@@ -161,7 +161,7 @@
#undef VMPAGESIZE
#define VMPAGESIZE _AST_PAGESIZE
#endif
-#if _lib_getpagesize
+#if defined(_lib_getpagesize) && !defined(VMPAGESIZE)
#define GETPAGESIZE(x) ((x) ? (x) : \
(((x)=getpagesize()) < VMPAGESIZE ?
((x)=VMPAGESIZE) : (x)) )
#else
-- snip --
[2] is elimited because in the current code the initial heap size is set
to the page size in "vmprivate.c" like this...
-- snip --
79 if(vd->incr <= 0) /* this is just _Vmheap on the first call */
80 vd->incr = _Vmpagesize;
-- snip --
... however the peak memory consumtion of a command like $ cut --man #
has a peak consumtion of around 28k which requires multiple |brk()|
calls. Bumping either the allocator page size to a higher value _xor_
replacing the line above with |vd->incr = _Vmpagesize*4;| fixes this.
After some more thinking I came up with the following diff:
-- snip --
Index: common/vmalloc/vmprivate.c
===================================================================
--- common/vmalloc/vmprivate.c (revision 1620)
+++ common/vmalloc/vmprivate.c (working copy)
@@ -77,7 +77,7 @@
#endif
if(vd->incr <= 0) /* this is just _Vmheap on the first call */
- vd->incr = _Vmpagesize;
+ vd->incr = INITIAL_VMHEAP_SIZE;
/* Get slightly more for administrative data */
s = size + sizeof(Seg_t) + sizeof(Block_t) + sizeof(Head_t) +
2*ALIGN;
Index: common/vmalloc/vmhdr.h
===================================================================
--- common/vmalloc/vmhdr.h (revision 1620)
+++ common/vmalloc/vmhdr.h (working copy)
@@ -161,12 +161,15 @@
#undef VMPAGESIZE
#define VMPAGESIZE _AST_PAGESIZE
#endif
-#if _lib_getpagesize
+#if defined(_lib_getpagesize) && !defined(VMPAGESIZE)
#define GETPAGESIZE(x) ((x) ? (x) : \
(((x)=getpagesize()) < VMPAGESIZE ?
((x)=VMPAGESIZE) : (x)) )
#else
#define GETPAGESIZE(x) ((x) = VMPAGESIZE)
#endif
+#ifndef INITIAL_VMHEAP_SIZE
+#define INITIAL_VMHEAP_SIZE ((_Vmpagesize)*4)
+#endif
/* Blocks are allocated such that their sizes are 0%(BITS+1)
** This frees up enough low order bits to store state information
-- snip --
This gives us two possible ways for tuning:
1. Setting |_AST_PAGESIZE| will define a static page size, avoiding the
(quite expensive) |sysconfig(_CONFIG_PAGESIZE)| call
2. The initial heap allocator size of now defined via
|INITIAL_VMHEAP_SIZE| and set to four times the default page size -
which is 4*8192 bytes on Solaris/SPARC and enougth that a plain $ cut
--man # call only needs one single |brk()| call. I've made this an extra
macro to control the value since an alternative solution may be to set
|_AST_PAGESIZE| to 64k (which allows to make active use of 64k MMU pages
on SPARC) and setting |INITIAL_VMHEAP_SIZE| to ((_Vmpagesize)*1) (since
4*64k would be too large as initial heap size)
Comments/rants/etc. welcome...
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-developers mailing list
[email protected]
https://mailman.research.att.com/mailman/listinfo/ast-developers
