I just stood up this environment and used nspins to max out the allocations.

Host (8 CPU v890)
        pool_1          Max=66K Min=1 Util_goal=50%     Actual 5
                zone_a  50 shares
                        proj_alpha 50 shares
                        proj_beta 50 shares
                zone_b  50 shares
        pool_2          Max=66K Min=1 Util_goal=50%     Actual 2
                zone_c  50 shares
        default_pool                                    Actual 1

Zones:
                zone_a  zone_b  zone_c
Global_Level    30%     30%     25%
Zone_level      50%     50%     100%

Projects:
                        zone_a  zone_b  zone_c
Global_Level_alpha      15%     
Global_Level_beta       15%
Global_Level_root               30%     25%
Zone_Level_alpha        25%
Zone_Level_beta         25%
Zone_Level_root                 50%     100%

- the zone split of 50%, 50%, and 100% makes sense. 50+50 = 100% in pool_1 and pool_2 reached 100% from zone_c

- zone_c only had rights to half of the pool's utilization goal so 1/2 of 50% is 25%. So the 25% makes sense.

If I had kicked of a project under pool_2 outside of zone_c, pool_2 would have stolen CPUs from pool_1 and the 30% would drop down to 25% each and the project would have dropped to 12%.

So the answer seems to be 12.5%. In the end I was just dividing a pie up into 8 parts.

Mike




Michael Barrett wrote:
Amol A Chiplunkar wrote:
You may want to add more information like you are creating
psets for each pool and the pset.max and pset.min of each.
Because when I create a pset without specifying them and associate it with a pool, the size is zero.

I thought when you were using a utilization goal instead of counting CPUs you should declare a max to be a really high, unrealistic number and the min to be 1. Is that not what you should do?


Also a correction. You cannot specify 50/100 shares. Shares are relative integer values and the absolute value of shares at any point of time can be calculated using total shares of of active entities competing for CPUs.

Yes, I know. But it's easier to follow the conversation instead of me putting 1 and 1 down or 6789 and 6789.


I would predict that the physical utilization of project_alpha in terms
of %CPUs (as shown by prstat) would be

(0.25 of poolsize of pool_1) * 100 / 16
i.e. if the pool_1 poolsize is 4, the physical utilization would be 6.25 %

That would mean I would have to know how many CPU are in the dynamic pool at any given time which I don't.


I expect that in order to have 50% utilization the objective will be set to ~50 value.
And pset.max will be set to a value more than 16.
In such a case, I would expect poold to try and give out as many cpus as possible to both the pools since the utilization needs to be kept at around 50% while
the zones and projects are fully utilizing all the CPU cycles they get.

Yes, that is what I want at the pool level.


So at one point, poold should reach a static configuration with pool_default with
only 1 CPU and the rest of them given to the two pools created.

So your saying the dynamic pool daemon with drive the box to a 16-1=15 then divide that by 2 and get 7.5 CPU bound to each pull. I just don't see why I need to care about counting threads (CPUs) when I already know the pool is using 50% of the box.


thanks
- Amol

----- Original Message -----
From: Michael Barrett <[EMAIL PROTECTED]>
Date: Friday, October 27, 2006 6:02 pm
Subject: [zones-discuss] actual utilization of a pool/zone/proj
To: zones-discuss@opensolaris.org

Lets say I have a T2000 with 16 threads.

I have the following:

pool_1 = dynamic pool with 50% utilization goal set
    zone_a = 50/100 shares
           proj_alpha = 50/100 shares
           proj_beta  = 50/100 shares
    zone_b = 50 shares
pool_2 = dynamic pool with 50% utilization goal set
    zone_c = 50/100 shares
    zone_d = 50/100 shares

To make the case more simple, we will state that all pools and zones and projects are running at the max so the constraints are being forced instead of one Solaris resource entity receiving more than he is allocated due to the FSS share model.

Is there anyway to estimate before seeing actual utilization what the physical utilization of proj_alpha would be? Would you just....

50% of the physical box to pool_1 divided by 50 shares for zone_a equals 25% of host utilization available for zone_a. Then 50% of 25% (25/50) is 12.5% of raw host utilization available for proj_alpha?

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



_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to