The following CR will reduce fragmentation and improve large
page availability:
6535949 availability of 2M pages degrades over time on Solaris/x64
The fix is in progress, and has a chance of making Solaris 10 U9.
As a workaround, you could experiment with the (unsupported) tunable
colorequiv. Solais is picky about choosing the best "color" for a
page during allocation, which can cause large pages to be broken up
to supply a small page of the correct color. In /etc/system, set
colorequiv to a value of 2, or 4, 8, 16, ... to make solaris
progressively less picky about coloring, and you may improve large
page availability. However, the downside is less optimal coloring,
which may increase the L2$ miss rate, so be conservative in raising
colorequiv.
- Steve
On 12/10/09 07:53, Nicolas Michael wrote:
Hi,
we're running our application (several 32bit processes, some 64bit as well) on Xeon 5500 series
> processors with 36G memory on Solaris 10 U7. In order to get at least some
large pages, we
> use -XX:+UseLargePages for our JVM's and MPSSHEAP=2M (with
LD_PRELOAD=mpss.so.1) for everything
> else. However, already after 2 days the amount of large pages that our
processes get ("pmap -sx")
is becoming less whenever a process (re)starts, resulting in a performance drop of about 10%. On
SPARC with enabled kernel cage we did not have such problems with memory fragmentation.
Afaik the kernel cage feature is not (yet) implemented for amd64, so I guess the reason for the
> memory fragmentation could be non-relocatable kernel memory. Are there any
ways to fight
> fragmentation on amd64? Or any other kernel parameters that I do not know
about that could help
> with fragmentation?
Thanks,
Nick.
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
