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 > is interleaved within board: > > > N0.SB0::memory connected configured ok base > > address 0x0, 33554432 KBytes total, 1768104 KBytes permanent > > N0.SB2::memory connected configured ok base > > address 0x2000000000, 16777216 KBytes total > > N0.SB4::memory connected configured ok base > > address 0x4000000000, 8388608 KBytes total > > The result of which is that the whole kernel resides in memory off the > board with so-called "permanent memory" -- memory that can't be removed > from the system. Any processor running the kernel will have to access > this range of memory, resulting in the CPUs on this board being busier > than those on the other boards, mostly handling xcalls. > > The reason we choose within-board interleaving as the default is to > support Dynamic Reconfiguration (DR) with which you can add or remove > boards without bringing the system down. > > To verify my theory, you can do the following: > # cfgadm -c unconfigure N0.SB0 (this will take a short while) > # cfgadm -c configure N0.SB0 > > Now if you run mpstat again, you will see CPUs off SB2 are busier than > the rest. > > There are ways to change this behavior, though not all are recommended > for many other reasons. One of the white papers I wrote many years ago > touched on this subject. I will see if I can dig it up if you are > interested. > > Sherry > -- > [EMAIL PROTECTED], Solaris Kernel Development, http://blogs.sun.com/sherrym -- [EMAIL PROTECTED], Solaris Kernel Development, http://blogs.sun.com/sherrym _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
