Mike Gerdts wrote:
I also like the idea of activating FSS if the zone.cpu-shares parameter is set. Given that activating FSS requires a reboot of the global zone, you should add a check to see if FSS is already active and if it is not, put out a warning message indicating that a reboot of the global is required to make FSS active. For that matter, there should be a warning message on zone boot that FSS is not active and the configured zone.cpu-shares value will be ignored.

No reboot is required.  See poolbind in this example:
http://users.tpg.com.au/adsln4yb/zones.html#resource_cpu1

Phil,

Mike as already responded with a bunch of useful information.
However, I looked at this url and on this one point regarding setting
FSS as the default, it doesn't look like it actually shows you how to
do this.

You don't have to reboot to make FSS the default and have all
of the global zones processes running under FSS.  Instead, you can
do something like this:

        # dispadmin -d FSS
        # dispadmin -u
        # priocntl -s -c FSS -i all
        # priocntl -s -c FSS -i pid 1

I see the -u option on dispadmin is undocumented.  I'll have to
look at that and see if it might make sense to raise its stability.
In the meantime, be aware that it could change at any time, although
that is not very likely.

Also, just to clarify things a bit in regards to our proposal, if you
have a zone with cpu-shares set, we won't be changing the global zones
scheduling class to be FSS.  While that would be useful for many
scenarios, it will change the behavior of the system and it might not
be what you want in all cases.  Instead, we will be setting up the zone
so that it is using FSS for all of its processes but the processes in
the global zone will continue to run with whatever scheduling class they
are using.  For a lot of cases with cpu-shares, it would probably be a good
idea to run with FSS as the default but we can't just make this change
to the system automatically.

Thanks,
Jerry
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to