[EMAIL PROTECTED] wrote:
> Quoting Roland Mainz <[EMAIL PROTECTED]>:
>
> I am missing something. How is the kernel wasting space with
> read/write string literals? You say 8-9 MB. How is changing this to
> read only going to make any difference (except to cause BAD TRAP
> panics when something tries to modify the literal)?
>From cc(1):
-- snip --
-xstrconst
Inserts string literals into the read-only data section
of the text segment instead of the default data seg-
ment. Duplicate strings will be eliminated and the
remaining copy shared amongst references in the code.
-- snip --
The important part is that duplicate string literals will be removed.
> As for fork, you make it sound like all read/write pages are copied
> everytime a fork is done. This should only be true for pages that are
> modified and copied due to copy-on-write. This should not be true of
> all read/write pages.
This should not be true, right. But the reality is that data are
shattered all over the place (see Frank Hoffman's reply).
[snip]
> As for making the compiler by default put string literals in read only
> segments, I would prefer the compiler to be less restrictive. I know
> what I'm doing, and if I do it incorrectly, it should be my problem,
> not the compiler's.
That's wrong and IMO a bug in your program then. "String literals" are
no "string buffers" and should not be used as such. The standard is
AFAIK clear on that and many compilers are even much clearer by putting
all string literals into read-only sections (like gcc4.x) without giving
you an option to change this.
> Also, the kernel stack space is not used for dynamically allocated
> space, except temporarily for stack frames for function calls. Oh, I
> see, you want to use the stack instead of kmem_alloc...??? If you
> make the kernel stacks very large, you run into virtual address size
> constraints on x86.
The kernel stacks for threads can AFAIK be one page.
For x86 this limits this to 4k or 2M/4M pages - unfortunately 2M/4M are
too large and therefore we may not be able to apply such an optimisation
to this platform.
UltraSPARC is in a better position in this case since it supports 8K,
64K, 512K and 4M pages (Niagara1 replaces 512k with 256MB pages) and IMO
64k pages offer the best tradeoff between more memory for stack
allocations and "wasted" memory.
> If the dynamic memory allocators are slow, fix
> them.
This was done all over the years. IMO new innovative ways are urgendly
needed and the general problem that the Solaris kernel (the same general
problem is present in the userland, too) is |kmem_alloc()|-happy needs
to be addressed from both sides:
1. Improve the kernel allocator
2. Reduce the number of calls to the kernel allocator.
My idea was to look at [2]. Right now many system calls result in a
memory allocation and I am looking for solutions to reduce this a little
bit... somehow.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [EMAIL PROTECTED]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
