Hi David,
Since your v1280 systems has NUMA characteristics, the bias that you see for
one of the boards may be a result of the kernel trying to run your
application's threads "close" to where they have allocated their memory. We
also generally try to keep threads in the same process together,
At a closer look, since you don't have another board with 33GB of
memory, I guess you won't be able to unconfigure N0.SB0.
Sherry
On Wed, Aug 31, 2005 at 03:36:01PM -0700, Sherry Moore wrote:
> Ah, just as I expected. :)
>
> On the Sun Fire series with multiple system boards, by default memory
>
Ah, just as I expected. :)
On the Sun Fire series with multiple system boards, by default memory
is interleaved within board:
> N0.SB0::memory connectedconfigured ok base
> address 0x0, 33554432 KBytes total, 1768104 KBytes permanent
> N0.SB2::memory
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
===
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 multip
I'm cleaning up the colunm layout for easier reading. See below:
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> David McDaniel (damcdani)
> Sent: Wednesday, August 31, 2005 4:14 PM
> To: perf-discuss@opensolaris.org
> Subject: [perf-discuss]
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 clas
