Sherry Moore [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 31, 2005 5:36 PM
> To: David McDaniel (damcdani)
> Cc: Sherry Moore; perf-discuss@opensolaris.org
> Subject: Re: [perf-discuss] Puzzling scheduler behavior
>
> Ah, just as I expected. :)
>
> On the Sun Fi
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
EMAIL PROTECTED],0/[EMAIL PROTECTED],60/[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:
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
gt; Subject: [perf-discuss] Puzzling scheduler behavior
>
> 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 t
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
