В вт, 03/11/2009 в 12:08 +0300, Alexander Pyhalov пишет:
> I have also noticed, that SRSS 4.2 is terribly slow on OpenSolaris build
> 126.
I have done a little work to try to narrow down the subjective redraw slowness
that I am seeing from 4.1 to 4.2.
* Fresh install of Osol 126.
* Fresh install of 4.2, I had to perform many of the hacks listed to get NSCM
running. Fresh install of 126 and 4.2 made no difference.
* Installing old 4.1 firmware made no difference.
* Turned on XRENDER, which seems to make Firefox a little faster.
I am more than a little stumped because CPU and network utilization are slower
under 4.2 than 4.1. Xterm is much faster than gnome-terminal on redraws.
Maybe this is some weirdo font issue?
I am running a Turion L2 which has a 512KB L2 cache, presumably shared between
the two cores.
I am starting to wonder if Xnewt's working set grew in size between 4.1 and
4.2, causing cache misses on smaller machines. I have never used cputrack
before, so I could be way off base here. I ran the following against the
primary Xnewt in the triple-head setup running Osol 126 and SRSS 4.2.
$ pfexec cputrack -T 1 -N 30 -c PAPI_l2_ich,PAPI_l2_icm -p 7598 > Xnewt.cputrack
During the sampling period I moved around virtual desktops causing lots of
redraw operations.
The output follows.
time lwp event pic0 pic1
1.015 1 tick 35595 15686
2.016 1 tick 13477 9830
3.015 1 tick 21318 12312
4.016 1 tick 137168 27670
5.015 1 tick 21838 7717
6.016 1 tick 22706 4294
7.018 1 tick 55755 6231
8.016 1 tick 90467 30179
9.016 1 tick 103697 39992
10.016 1 tick 162279 43373
11.016 1 tick 358338 65504
12.017 1 tick 47725 20075
13.016 1 tick 229462 35378
14.017 1 tick 227653 32036
15.017 1 tick 164112 35157
16.016 1 tick 27118 3689
17.017 1 tick 25974 4751
18.016 1 tick 21923 2158
19.017 1 tick 309315 44520
20.017 1 tick 189400 44045
21.017 1 tick 328216 45172
22.017 1 tick 234171 32971
23.017 1 tick 196143 30683
24.017 1 tick 79192 30028
25.008 1 tick 84344 32607
26.017 1 tick 68979 28282
27.017 1 tick 120616 28368
28.018 1 tick 18613 4769
29.017 1 tick 25599 5077
30.018 1 tick 22877 4436
Then I calculated the instruction hit ratio of the L2 cache.
$ cat Xnewt.cputrack | sed "s/ */ /g" | sed -n "2,$ p" | cut -d" " -f5,6 | sed
"s/ / d /" | sed "s/$/ 4 k +\/p/" | dc
I received what appears to be a pretty bad hit ratio over the period.
.6941
.5782
.6338
.8321
.7388
.8409
.8994
.7498
.7216
.7890
.8454
.7039
.8664
.8766
.8235
.8802
.8453
.9103
.8741
.8113
.8790
.8765
.8647
.7250
.7211
.7092
.8095
.7960
.8344
.8375
It is entirely possible, if not probable, that my sampling and math are wrong
on this. If correct, this says Xnewt's L2 instruction hit ratio hovers between
70% and 90%. I don't know what a "good" hit ratio is, but I would imagine that
it would consistently exceed 95%.
Given the horrid memory latency/throughput that Turions are known for, would
this explain the drop in performance?
I am a little hesitant to fall back to 4.1 and rerun the tests, but if it would
help, I will try to do so this coming weekend.
All feedback appreciated.
Sincerely,
Marty
_______________________________________________
SunRay-Users mailing list
[email protected]
http://www.filibeto.org/mailman/listinfo/sunray-users
