Jonathan Adams wrote: > > On Mon, Jul 10, 2006 at 11:35:31AM -0700, Alexander Kolbasov wrote: > > > [EMAIL PROTECTED] wrote: > > > > >Offtopic: Which still reminds me to write an email about that the > > > > >Solaris kernel is very very malloc()-happy (which is unneccesary in > > > > >many > > > > >cases now that C99-sematics are allowed). > > > > > > > > You are wrong. > > > > > > Thank you... ;-(( > > > See below... > > > > > > > We *malloc* not because of shortcomings in C but because > > > > we don't have any room on the stack to put stuff. > > > > > > - Create a C macro |#define KMEM_TMP_ALLOC()| which expands to the > > > following procedure: > > > 1. Measure stack size and current available space on stack. The first > > > 512bytes (of a 8k default stack, a 64k default stack would offer much > > > more room (this value is a tuneable, setting it to |0| will disable the > > > stack allocations)) are available to allocations via C99 constructs (if > > > this fails the size will simply be set to |0|). > > > > Are there lots of such tmp allocations in the kernel to justify such > > special-purpose allocator? Most of the allocations seem to be used for data > > structures - they are not temporary. > > And in any case, the benefits of debugging the kernel allocator has would be > lost with this.
This applies to normal array on the stack, too. I doubt this is as harmfull as you are thinking... > And knowing "how much" stack you need to leave is a very > tricky business. I just hacked a small add-on which marks the end of the stack with 0xdeadbeef - it seems the lower 512bytes are never touched by anything. I'd say it's at least safe to assume we can grab 128bytes for such allocations - and likely even more (note that the original proposal made the exact value a tuneable - which means we can always turn this off or choose a different value on demand). And then there is the option to switch to 64k pages on SPARC, giving MUCH more room for this kind of allocations (including those in the device drivers). ---- 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
