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.
>> 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
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.
zones-discuss mailing list