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