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

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...

zones-discuss mailing list

Reply via email to