On Thu, Mar 5, 2009 at 9:15 AM, Bob Netherton <bob.nether...@gmail.com> wrote: > >> 1. Do you use "set pool=" anymore, now that the dedicated-cpu feature exists? > > Until Oracle develops a more rational licensing scheme you should > expect this feature to be in use. I may have many Oracle instances, > each in a separate zone, using the same pool.
Good point. I was thinking of Oracle licensing with dedicated-cpu, but didn't assign enough importance to the model you mentioned. > The sampling on this discussion list may not give you a good idea of its use. > Might > pose this question on your blog as well ? A capital idea! > That said, this requires manual configuration of the pool. To which 'this' do you refer? The current use of "set pool=" or my proposed property "set interrupts=disabled"? > I don't think it would be asking too much for customers using this feature to > also set up a boot time service (SMF or RC) to disable interrupts on all CPUs > in the pool. I think you are saying "I don't think there is a need for set interrupts=disabled' because that can be accomplished in an SMF service or RC script." If you are not saying that, I apologize for mis-interpreting and ask that you help me understand. But assuming I got it right the first time... :-) ...I respectfully disagree, for the following reasons: 1. Few people know how to create an SMF service. I don't know how to do that. I'm confident that I could learn - probably by reading your blog :-) - but it's not something I have ever done. We have been telling people to not use RC any more, so I don't consider RC a viable option. 2. The step that disables interrupts for a zone's CPUs should be equally applicable whether the zone uses a "permanent pool" (via "set pool=") or a temporary pool (via dedicated-cpu). It's not possible to disable interrupts on a temporary pool at boot time because it doesn't exist yet, so we would be recommending SMF for permanent pools and adding a new feature for dedicated-cpu, which is unnecessarily confusing and might require learning more about SMF than most people want to learn. (Imagine telling someone that to use an SMF feature they must learn how to create a zone.) 3. The configuration information specifying disabled interrupts for a zone should move with the zone via zoneadm... detach/attach. That will happen with zonecfg, but will not happen with SMF/RC. >> 2. Is it sufficient to simply disable interrupts on a zone's pset? > > I like your idea of turning off interrupts for dynamic resource pools > under zoneadm/rcapd control, and leaving it a configurable item. I > would also think that when CPUs are removed from the pool that > interrupts should be turned back on unless given to a another > pool with interrupts=disabled. I would hate for several zone > reboots to turn off interrupts to all CPUs :-( Oh, I don't know, ;-) I function better without interruptions... Seriously, that's a good point. Fortunately, Solaris prevents that from happening - see psradm(1M)). The final proposal should require that zoneadm check the return code from p_online(2) and the zone must not boot if the calls fails and the return code is EBUSY. In addition, some consideration should be given to this type of situation: many zone re-boots could shift all interrupt handling to one CPU, which might be a CMT thread... Perhaps there should be a system tunable for "minimum portion of the system's CPUs which must be enabled for interrupts." Or perhaps this becomes one of the many ways that Solaris allows one to shoot oneself in the foot... --JeffV _______________________________________________ zones-discuss mailing list zones-discuss@opensolaris.org
