Its always something: # cfgadm -c unconfigure N0.SB0 System may be temporarily suspended, proceed (yes/no)? y cfgadm: Hardware specific failure: unconfigure N0.SB0: No available memory target: /[EMAIL PROTECTED],0/[EMAIL PROTECTED],400000
In any case, yes if you could dredge up the paper that would be educational. So if I understand you, would I be correct in concluding that if I am going to tune the system by binding selected processor sets I can achieve better results if I choose cpu on boards other than SB0? Or is that too naïve? -d > -----Original Message----- > From: 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 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 > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
