On Thu, Mar 05, 2009 at 01:22:25PM -0500, Jeff Victor wrote:
> Thanks for the great feedback Gael. Comments below.
> On Thu, Mar 5, 2009 at 11:00 AM, Gael <gael.marti...@gmail.com> wrote:
> >
> > On Wed, Mar 4, 2009 at 9:06 AM, Jeff Victor <jeff.j.vic...@gmail.com> wrote:
> >>
> >> Some questions:
> >> 1. Do you use "set pool=" anymore, now that the dedicated-cpu feature 
> >> exists?
> >
> > We got over one hundred physical frames running zones here, covering nearly
> > all versions of Solaris 10, we are currently sticking to set pool until we
> > can get the whole environment upgraded. Before that, cannot afford to have
> > the whole team of admins handling zones differently depending on the OS
> > version. Headache...
> It is now clear to me that this feature would need to support
> disabling interrupts when a zone uses "set pool=". Currently, all pool
> attributes are configured using the pool tools (poolcfg, pooladm) and
> I don't see any reason to not continue. When I write this up, it will
> fulfill that need.

Ae you proposing that we add support for pset-interrupt disposition config
to the pools framework?  Such as a property on a pool-pset
        "boolean pset.interrupts = false"??

I think the right solution for "pool=" is this or similar.  It could also
be a string value, such as:

        "none"  no interrupts handled on cpus in the pool-pset.
        "zone"  Device interrupts for bound zones are serviced.
        "any"   Any device interrupts can be dispatched to the pset.

Zonecfg could make use of these pool-pset properties to implement the
desired behavior for "dedicated-cpu".

The default value should be "any".  zonecfg should set "zone" for all
dedicated-cpu zones.  zoneadm could warn if "pool=" is set, the zone has
dedicated devices, zone the pset for that pool has not been configured to
be "zone".

legacy psets (psrset) could be extended to support this property via some
new flags.

Ther other part of this is how to reconsile zonecfg and/or pools settings
for interrupts, with device-cpu mappings that are specified via dladm.
Currently, dladm allows the specification of a list of cpu ids.  Another
way to approach this would be to point dladm directly at the desired pool.

> >> 2. Is it sufficient to simply disable interrupts on a zone's pset?
> >
> > In our case, we do pset only when licensing requires it (aka
> > oracle,datastage,sybase,borland apps) or when the applications behave poorly
> > and we keep hearing that by lack of budget/resources, the issue cannot be
> > addressed and without direct impact on the business itself, nothing will
> > change.
> Gael, I realized that my question was vague. When you use a pool,
> you're using a pset. Do you mean that you only use pools and psets
> when licensing requires it?
> Also, I couldn't tell how the comment responded to the question.
> > What about creating an IO pset, and then disabling the interrupt on
> > everything else while using it as a FSS pool or psets pools ? Very similar
> > to ldom I would think...
> Yes, that occurred to me, too. You can do that now, either with a pset
> that's being used by a zone or with the default pset. But I'm not
> convinced there's enough reason to separate an I/O pset from the
> default pset. There's great potential for wasted CPU cycles.
> --JeffV
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org
zones-discuss mailing list

Reply via email to