PS, I know this can be managed by using processor sets and binding, I'm
just trying to understand the defaults...
As requested:
# /usr/sbin/prtdiag
System Configuration: Sun Microsystems sun4u Sun Fire V1280
System clock frequency: 150 MHz
Memory size: 57344 Megabytes
========================= CPUs =========================
Run Ecache CPU CPU
Brd CPU Module MHz MB Impl. Mask
--- --- ------- ----- ------ ------ ----
0 0 0 900 8.0 US-III+ 2.3
0 1 1 900 8.0 US-III+ 2.3
0 2 2 900 8.0 US-III+ 2.3
0 3 3 900 8.0 US-III+ 2.3
0 8 8 900 8.0 US-III+ 2.3
0 9 9 900 8.0 US-III+ 2.3
0 10 10 900 8.0 US-III+ 2.3
0 11 11 900 8.0 US-III+ 2.3
0 16 16 900 8.0 US-III+ 2.3
0 17 17 900 8.0 US-III+ 2.3
0 18 18 900 8.0 US-III+ 2.3
0 19 19 900 8.0 US-III+ 2.3
========================= IO Cards =========================
# cfgadm -av
Ap_Id Receptacle Occupant Condition
Information
When Type Busy Phys_Id
N0.IB6 connected configured ok
powered-on, assigned
Aug 31 16:51 PCI_I/O_Boa n /devices/[EMAIL PROTECTED],0:N0.IB6
N0.IB6::pci0 connected configured ok
device /[EMAIL PROTECTED],0/[EMAIL PROTECTED],700000, referenced
Aug 31 16:51 io n /devices/[EMAIL PROTECTED],0:N0.IB6::pci0
N0.IB6::pci1 connected configured ok
device /[EMAIL PROTECTED],0/[EMAIL PROTECTED],600000, referenced
Aug 31 16:51 io n /devices/[EMAIL PROTECTED],0:N0.IB6::pci1
N0.IB6::pci2 connected configured ok
device /[EMAIL PROTECTED],0/[EMAIL PROTECTED],700000
Aug 31 16:51 io n /devices/[EMAIL PROTECTED],0:N0.IB6::pci2
N0.IB6::pci3 connected configured ok
device /[EMAIL PROTECTED],0/[EMAIL PROTECTED],600000, referenced
Aug 31 16:51 io n /devices/[EMAIL PROTECTED],0:N0.IB6::pci3
N0.SB0 connected configured ok
powered-on, assigned
Aug 31 16:51 CPU n /devices/[EMAIL PROTECTED],0:N0.SB0
N0.SB0::cpu0 connected configured ok
cpuid 0, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB0::cpu0
N0.SB0::cpu1 connected configured ok
cpuid 1, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB0::cpu1
N0.SB0::cpu2 connected configured ok
cpuid 2, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB0::cpu2
N0.SB0::cpu3 connected configured ok
cpuid 3, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB0::cpu3
N0.SB0::memory connected configured ok base
address 0x0, 33554432 KBytes total, 1768104 KBytes permanent
Aug 31 16:51 memory n /devices/[EMAIL PROTECTED],0:N0.SB0::memory
N0.SB2 connected configured ok
powered-on, assigned
Aug 31 16:51 CPU n /devices/[EMAIL PROTECTED],0:N0.SB2
N0.SB2::cpu0 connected configured ok
cpuid 8, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB2::cpu0
N0.SB2::cpu1 connected configured ok
cpuid 9, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB2::cpu1
N0.SB2::cpu2 connected configured ok
cpuid 10, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB2::cpu2
N0.SB2::cpu3 connected configured ok
cpuid 11, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB2::cpu3
N0.SB2::memory connected configured ok base
address 0x2000000000, 16777216 KBytes total
Aug 31 16:51 memory n /devices/[EMAIL PROTECTED],0:N0.SB2::memory
N0.SB4 connected configured ok
powered-on, assigned
Aug 31 16:51 CPU n /devices/[EMAIL PROTECTED],0:N0.SB4
N0.SB4::cpu0 connected configured ok
cpuid 16, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB4::cpu0
N0.SB4::cpu1 connected configured ok
cpuid 17, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB4::cpu1
N0.SB4::cpu2 connected configured ok
cpuid 18, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB4::cpu2
N0.SB4::cpu3 connected configured ok
cpuid 19, speed 900 MHz, ecache 8 MBytes
Aug 31 16:51 cpu n /devices/[EMAIL PROTECTED],0:N0.SB4::cpu3
N0.SB4::memory connected configured ok base
address 0x4000000000, 8388608 KBytes total
Aug 31 16:51 memory n /devices/[EMAIL PROTECTED],0:N0.SB4::memory
c1 connected configured unknown
unavailable scsi-bus n
/devices/[EMAIL PROTECTED],0/[EMAIL PROTECTED],600000/[EMAIL PROTECTED]:scsi
c1::dsk/c1t0d0 connected configured unknown
FUJITSU MAN3367M SUN36G
unavailable disk n
/devices/[EMAIL PROTECTED],0/[EMAIL PROTECTED],600000/[EMAIL
PROTECTED]:scsi::dsk/c1t0d0
> -----Original Message-----
> From: Sherry Moore [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 31, 2005 4:47 PM
> To: David McDaniel (damcdani)
> Cc: perf-discuss@opensolaris.org
> Subject: Re: [perf-discuss] Puzzling scheduler behavior
>
> Hi David,
>
> I have a theory. But before I present it, I would like a bit
> more information.
>
> - Output of "/usr/sbin/prtdiag"
> - If it is a Sun Fire, the output of "cfgadm -av"
>
> Thanks,
> Sherry
>
> On Wed, Aug 31, 2005 at 02:13:47PM -0700, David McDaniel wrote:
> > Our application consists of multiple cooperating
> multithreaded processes. The application is both latency and
> throughput sensitive. Since it originated long ago, several
> artifacts are less than optimal, but thats the way it is for
> awhile longer. Anyway, I digress. Most threads run in the TS
> class with boosted "nice" values so as to limit the possible
> interference from the the occasional background task; the
> exceptions are a few very lightweight, infrequent, but urgent
> ones that run in the RT class. Additionally, hires tick is
> set. As a result, the default rechoose_interval period is 3ms
> rather than the normal 30ms.
> > The curious thing is that on a 12 cpu system I can
> observe that some cpus are much busier than others, and
> latency as observed via prstat -Lm is higher than expected on
> a lightly loaded system. I presume this is an artifact of
> threads queueing up for rechoose_interval on the last cpu
> they ran on instead of migrating. This seems to be born out
> by the fact that I can use psrset to create a set containing
> one of the otherwise idle cpus, bind a process to it, then
> delete the processor set and see that the previously bound
> process appears to stick on the previously idle cpu. OK, so
> far, but the other processes still seem to be contending for
> busy cpus, which is inoptimal for our application.
> > Now comes the real puzzler, to me at least. I set
> rechoose_interval=0 in /etc/system, reboot, take it from the
> top. I though this would result in the load being spread out
> over time as threads migrated to and then stuck to
> uncontended cpus, but thats not what I see. Here is mpstat snapshot:
> > CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl
> usr sys wt idl
> > 0 14 0 211 2976 1957 2245 84 375 156 0
> 20874 17 9 0 74
> > 1 0 0 149 98 2 2612 89 583 73 0
> 19032 16 11 0 73
> > 2 12 0 184 86 6 2523 76 589 76 0
> 17215 13 9 0 77
> > 3 0 0 96 650 581 2387 64 530 85 0
> 13249 11 7 0 82
> > 8 56 0 11 6 1 581 2 227 25 0
> 1401 2 2 0 97
> > 9 0 0 6 4 1 550 0 111 8 0
> 398 1 1 0 98
> > 10 5 0 8 28 25 546 0 44 14 0
> 165 0 1 0 99
> > 11 0 0 16 390 388 219 0 23 18 0
> 75 0 1 0 99
> > 16 52 0 13 10 7 223 1 22 5 0
> 212 0 1 0 99
> > 17 0 0 5 4 1 322 0 34 5 0
> 525 0 1 0 99
> > 18 0 0 15 5 1 319 1 86 11 0
> 1558 1 1 0 98
> > 19 1 0 50 8 1 552 4 192 22 0
> 4406 4 2 0 94
> >
> > Any thoughts?
> > This message posted from opensolaris.org
> > _______________________________________________
> > perf-discuss mailing list
> > perf-discuss@opensolaris.org
>
> --
> [EMAIL PROTECTED], Solaris Kernel Development,
> http://blogs.sun.com/sherrym
>
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
