Michael Corcoran wrote: > On Thu, 2007-06-14 at 09:12 -0500, Dave Marquardt wrote: > > "Roland" == Roland Mainz <roland.mainz at nrubsig.org> writes: > > > > Roland> Dave Marquardt wrote: > > >> > > >> "dsc" == David Comay <David.Comay at Sun.COM> writes: > > >> > > dsc> Here are my comments for round "three": > > >> > > dsc> usr/src/cmd/ksh/Makefile.com > > >> > > dsc> Lines 101-109 - As I indicated in an earlier review, I don't > > dsc> believe this is necessary. Both Nevada and the Solaris 10 > > dsc> patch gate do large pages automatically (or so-called out of > > dsc> the box) and so including these options is unnecessary. > > dsc> However, I've cc'ed Bart Smaalders who is an expert in this > > dsc> area who can suggest whether or not it makes sense to include > > dsc> this. > > >> > > >> Just to be clear, this issue is about using -xpagesize_heap=64K and > > >> -xpagesize_stack=64K on SPARC. > > > > Roland> Right... > > > Just to be even clearer, is this for all SPARC machines or just > UltraSparc I and II machines?
Erm... yes, it's for all SPARC machines. > The TLB architecture on US-III+, US-IV, US-IV+ tends not to use 64K page > sizes often due to the restriction of having essentially 2 pagesizes > within a process that work well together. US-III may not work well with > 2 page sizes though and thus we default to 8k in sun4u/cpu/us3_cheetah.c > cpu_fiximp. Erm... doesn't UltraSPARC >= 3cu have three pagetables which can handle one specific page size each (with the restriction that the current Solaris _implementation_ restricts this to 8k and 4M pages (which is IMO sub-optimal since the majority of smaller applications cannot make much use of 4M or 512k pages - for example the Xserver would run a lot better when offscreen surfaces would be mapped with 64k pages) ... and another good example are gzip, bzip2 and libz.so.1 where the use of 64k pages shows a good performance improvement even on a Blade1000 which cannot handle 64k pages that well...) ? And AFAIK there is a 16entry table which can handle any supported page size - which at least makes the use of 64k pages useable for the stack (assuming the users don't consume lots of memory and/or don't make large jobs between multiple pages) since there aren't that many stack pages (and the usage/access pattern is very different from the heap usage/access pattern). > The Niagara cpus I think can handle all page sizes equally well. Right... AFAIK it's a derivate of the Spitfire MMU and doesn't have any restrictions like that. ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
