Dave Marquardt wrote:
> "Mike" == Michael Corcoran <Michael.Corcoran at Sun.COM> writes:
[snip]
> Mike> Just to be even clearer, is this for all SPARC machines or just
> Mike> UltraSparc I and II machines?
>
> I believe it's in the Makefile in sparc_CFLAGS and sparcv9_CFLAGS, so
> I assume it applies to all SPARC machines.
It's for all SPARC machines but based on the discussion it may be better
to remove the option for "heap" ....
... however mapping the stack with 64k pages is a different story. The
stack usage in ksh93 has been optimized to use more stack (instead of
global variables), assuming a default page size of 64k. And this doesn't
collide with the problem that the current MMU code implementation for
UltraSPARC-3/4 "hardcodes" 8k+4M pages for the two(=US-3)/three(US >=
3cu) large tables since we can easily use MMU page slots from the
16entry set for the stack without risking any problems with any existing
MMU design - and this assumption is backed by benchmarks from a
Blade1000 and SF68k/SF69k (the stack usage exceeds the "range" of the 16
slot set but it is still faster than using 8k pages):
-- snip --
$ (time env - LC_ALL=C
~/ksh93/ast_ksh_20070515/build_normal_8k_stack/arch/sol11.sun4/bin/ksh
-c 'for ((j=0 ; j < 5000 ; j++ )) ; do integer i=0 ; function incnum {
(( i++ , i < 900 )) && incnum ; } ; incnum ; done' )
real 2m4.183s
user 2m2.896s
sys 0m0.119s
$ (time env - LC_ALL=C
~/ksh93/ast_ksh_20070515/build_normal_64k_stack/arch/sol11.sun4/bin/ksh
-c 'for ((j=0 ; j < 5000 ; j++ )) ; do integer i=0 ; function incnum {
(( i++ , i < 900 )) && incnum ; } ; incnum ; done' )
real 1m59.337s
user 1m58.109s
sys 0m0.123s
-- snip --
Or short: Even on machines with a "crippled" MMU (I don't have better
words for the UltraSPARC-3/4 MMU design (Ok... half of my wrath go into
the direction of the Solaris MMU code which uses 8k+4M pages instead of
8k+<preferred_largepage_size_of_process> ... ;-( ) ... ;-( ) show a four
second performance improvement for "free" - by setting
-xpagesize_stack=65536 ... :-)
(Another issue is the "hit&&run" usage of the shell - see
http://mail.opensolaris.org/pipermail/ksh93-integration-discuss/2007-June/002717.html
for the real-world example where things like the "LargePage Our Of the
Box" code doesn't work).
> Mike> The TLB architecture on US-III+, US-IV, US-IV+ tends not to use 64K page
> Mike> sizes often due to the restriction of having essentially 2 pagesizes
> Mike> within a process that work well together. US-III may not work well with
> Mike> 2 page sizes though and thus we default to 8k in sun4u/cpu/us3_cheetah.c
> Mike> cpu_fiximp.
>
> Mike> The Niagara cpus I think can handle all page sizes equally well.
>
> Well, except 512KB and 32MB, which don't exist on Niagara 1.
Will Niagara2 bring the 512k pages back (which are IMO usefull for
pixmap memory in the Xserver&co.).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
