HiperDispatch Logical Processors and Weight Management

Transcription

1 HiperDispatch Logical Processors and Weight Management Fabio Massimo Ottaviani EPV Technologies August Introduction In the last few years, the power and number of the physical processors available on mainframe hardware has greatly increased, allowing the concentration of a much higher number of LPARs than before on a single machine. A side effect of this high number of LPARs is an increase of the number of defined logical processors compared to the number of physical CPs. These factors tend to reduce the probability for a logical processor to be re-dispatched to the same physical processor and therefore reuse instructions and data previously loaded in the Level 1 cache (the amount of cache memory dedicated to each processor). A L1 cache miss will cause data and instructions to be loaded from the Level 2 cache (the cache memory shared among all the physical processors packaged in a book). Performance degradation and overhead occurs when this happens because the access to L2 cache will require more CPU cycles to be performed. However if the logical processor has been dispatched to a different physical processor which belongs to a different book, the required instructions and data have to be loaded from the previously used L2 cache and performance degradation and overhead can be much worse. HiperDispatch has been designed to minimise the number of L1 cache misses and, if a L1 cache miss occurs, to maximise the probability of finding instructions and data in the L2 cache of the book where the logical processor is dispatched. To reach this goal, a new weight called polarization weight has been introduced; polarization weight is a key element in the HiperDispatch design because it is the way z/os uses to give PR/SM indications on how logical processors should be dispatched to the physical processors. This paper, using real life examples, will discuss: PR/SM and IRD logical processors and weight management; HiperDispatch logical processors and weight management. 2 PR/SM Logical Processors and Weight Management Logical processors are the LPAR view of physical processors. A logical processor can be defined as dedicated or shared. When an LPAR using dedicated logical processors is activated, a physical processor is assigned to each one of them. The LPAR then has exclusive use of these physical processors. This is true for any processor type such as standard CPUs, AAPs, IIPs, etc. Dedicated logical processors are not relevant for the scope of this paper so, in the following, only shared logical processors will be discussed. When logical processors are defined as shared, a LPAR does not have exclusive use of the physical processors but have to share them with other LPARs. HiperDispatch Logical Processors and Weight Management 1

2 The maximum number of shared logical processors which can be assigned to each LPAR is the number of physical processors in the shared pool 1. This means that the total number of shared logical processors defined in all the LPARs can be much larger than the number of physical processors to share. For example, if five LPARs are active on a 8 CPU machine, the shared pool is 8 CPUs, and each LPAR has 8 logical processors defined, the total number of logical processors is 40. The PR/SM configuration of a 13 CPU machine hosting 5 LPARs is presented in Figure 1. The total number of shared logical processors (SHARED CPUs) is 33 that is 2,54 times the number of physical processors to share. LPARNAME SHARED CPUs LPAR % TARGET CPUs LPAR % 6,76 LPAR % 0,52 LPAR % 0,33 LPAR % 2,99 LPAR % 2, % 13,00 Figure 1 To determine the portion of the shared pool to be used by each LPAR, PR/SM uses LPAR weights (LPAR ). The algorithm used by PR/SM is the following: add the weights of all active, sharing LPARs; this total is considered to be 100% of the processing resource available in the shared pool; divide each LPAR weight by the total; the resulting percentage is the target share of processing resources for each LPAR (%). LPAR1 has a weight of 520 which is 52% of the sum of all LPAR weights. So LPAR1 target share is 52% of the number of shared CPUs in the pool (13 in this case) which corresponds to the use of 6,76 CPUs (TARGET CPUs). It s interesting to note that LPAR2 has a very low weight but a high number of shared logical processors (SHARED CPUs). That could make sense because PR/SM enforces LPAR weights only when all the LPARs want to use their target share or more. When there is available capacity, one or more LPARs may use more than their targets, up to the number of online shared CPUs. With these definitions LPAR2 may use only 50% of one CPU when in contention (TARGET CPUs) but up to the full power of the machine if the other LPARs are not active or very lightly loaded. Having this flexibility is one of the reasons why many customers designed configurations where each LPARs has assigned all the logical processors of the shared pool. Unfortunately, a high logical to physical processors ratio is one of the main sources of PR/SM overhead. In fact having so many logical processors to manage increases PR/SM s work and makes 1 The number of physical processors in the shared pool is the total number of physical processors minus the number of dedicated processors. Since z9 machines each processors type (CPU, AAP, IIP, ICF and IFL) has its own separate shared pool. HiperDispatch Logical Processors and Weight Management 2

3 much more unlikely the re-dispatching of a logical processor to the same physical processor used before. Another important issue to consider is that the number of logical processors and the target share of a LPAR are used by PR/SM to determine the time slice each logical processor can use of a physical processor every time it is dispatched. LPARNAME SHARED CPUs LPAR % TARGET CPUs %CPU LPAR % 6,76 85% LPAR % 0,52 4% LPAR % 0,33 16% LPAR % 2,99 75% LPAR % 2,41 40% % 13,00 Figure 2 The %CPU column reports the values PR/SM would use in this configuration to set time slice values for the logical processors of each LPAR. They have been calculated dividing TARGET CPUs by SHARED CPUs. LPAR2 values is only 4%. This means that its logical processors have to be dispatched many times (25) to use the full power of a CPU. Increasing the number of times a unit of work has to be dispatched to complete will increase the PR/SM overhead and more importantly the times a logical processor has to queue with consequent performance degradation. This is what the IBM Washington System Center calls the Short CP effect. In the same machine 2 IIPs are also used. Figure 3 shows the correspondent PR/SM configuration. LPARNAME SHARED IIPs LPAR % TARGET IIPs %IIP LPAR % 0,93 47% LPAR % 0,23 11% LPAR % 0,08 4% LPAR % 0,70 35% LPAR % 0,05 2% % 2,00 Figure 3 Starting from z9 hardware AAPs and IIPs are managed by PR/SM in the same way as standard CPUs. 3 PR/SM Logical Processors and Weight Management with IRD A possible solution to reduce PR/SM overhead and maintain the needed flexibility is to use the standard z/os CONFIG command to reduce or increase the number of logical processors available to each LPAR. Some companies do that manually or by using automation scripts but normally the variation of the number of logical processors is minimal and pre determined (often based on time shift, day of the week, etc) and not correlated to system load and application performance. A much better solution has been provided by IBM for some years with the Intelligent Resource Director (IRD). HiperDispatch Logical Processors and Weight Management 3

4 IRD is a set of functions designed to distribute hardware resources based on business importance. They are: LPAR Vary CPU Management; LPAR Weight Management; Dynamic Channel Path Management; Channel Subsystem Priority Queuing. Only the first two are relevant for the scope of this paper: LPAR Vary CPU Management is designed to maintain online the minimum number of logical processors required by an LPAR to use the capacity that corresponds to its target share; LPAR Weight Management is designed to adjust weights for the LPARs belonging to the same IRD cluster in order to better match workload demand and importance. An IRD cluster is composed of all the LPARs belonging to the same Sysplex and running on the same physical machine. SYSPLEX LPARNAME IRD CLUSTER SHARED CPUs LPAR CURRENT % TARGET CPUs %CPU SYSPLEX1 LPAR1 CLUSTER % 6,40 91% SYSPLEX1 LPAR2 CLUSTER % 0,83 42% SYSPLEX2 LPAR3 CLUSTER % 0,33 16% SYSPLEX1 LPAR4 CLUSTER % 3,04 76% SYSPLEX3 LPAR5 CLUSTER % 2,41 80% % 13,00 Figure 4 In Figure 4 you can appreciate the effect IRD on our configuration. Reported values are based on the situation at a specific point in time (10:00 am in this case) because, as described, IRD can dynamically change the number of logical processors and the LPAR weights. The number of logical processors of LPAR1, LPAR2, LPAR4 and LPAR5 have been reduced 2. The total number of shared logical processors (SHARED CPUs) is now 18 that is 1,38 time the number of physical processors to share. The weights of LPAR1, LPAR2 and LPAR4, all belonging to CLUSTER1, has been adjusted (see CURRENT ). No actions have been taken on LPAR3 and LPAR5 weights because they are the only LPAR respectively in CLUSTER2 and CLUSTER3. When IRD is active, the standard LPAR weight becomes the initial weight. Using that as a starting point, IRD will set the current weight using the indications of WLM and finally with respect to the minimum and maximum weight values set by the user. It s interesting to note that the total weight of all the LPARs in a cluster can not change (because otherwise the weights adjustment could impact another Sysplex). 2 The minimum number of online logical processors can be specified in the VARYCPUMIN parameter in the IEAOPTxx member of SYS1.PARMLIB. VARYCPUMIN(2) has been specified for all the LPARs in the analysed configuration; this is the reason why LPAR3 logical processors have not been reduced. HiperDispatch Logical Processors and Weight Management 4

5 So in Figure 4, the sum of the CLUSTER1 initial weights (LPAR ) and current weights (CURRENT ) is exactly the same (790). We can say that IRD did a good job by reducing the number of logical processors and, looking at the last column, also the Short CP effect (especially for LPAR2). Unfortunately IRD design has some important limitations: 1) It provides no information to PR/SM on the way logical processors should be dispatched to reduce cache miss performance degradation and overhead; 2) Weight management is only possible for LPARs belonging to the same cluster; 3) It only manages standard CPUs; not AAPs or IIPs. 4 Polarization Weights A key element in the HiperDispatch design is a new metric called polarization weight which represents the weight automatically assigned to a logical processor by z/os. In the following table a comparison is done among LPAR weights, IRD current weights and polarization weights. Reported values are based on the situation at a specific point in time (10:00 a.m. in this case) because HiperDispatch can dynamically change the number of logical processors and their weights. SYSPLEX LPARNAME IRD CLUSTER ADDR LPAR CURRENT POW SYSPLEX1 LPAR1 CLUSTER SYSPLEX1 LPAR1 CLUSTER SYSPLEX1 LPAR1 CLUSTER SYSPLEX1 LPAR1 CLUSTER SYSPLEX1 LPAR1 CLUSTER SYSPLEX1 LPAR1 CLUSTER SYSPLEX1 LPAR1 CLUSTER SYSPLEX1 LPAR1 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX1 LPAR2 CLUSTER SYSPLEX2 LPAR3 CLUSTER SYSPLEX2 LPAR3 CLUSTER SYSPLEX1 LPAR4 CLUSTER SYSPLEX1 LPAR4 CLUSTER SYSPLEX1 LPAR4 CLUSTER SYSPLEX1 LPAR4 CLUSTER HiperDispatch Logical Processors and Weight Management 5

6 SYSPLEX3 LPAR5 CLUSTER SYSPLEX3 LPAR5 CLUSTER SYSPLEX3 LPAR5 CLUSTER SYSPLEX3 LPAR5 CLUSTER SYSPLEX3 LPAR5 CLUSTER SYSPLEX3 LPAR5 CLUSTER Figure 5 If HiperDispatch was not active, the LPAR current weights, set by IRD, would be evenly distributed among all the logical processors. So, to allow a comparison, the column in Figure5 has been calculated dividing the LPAR current weight (CURRENT ) by the number of logical processors 3. It s important to note that IRD is no longer reducing the number of logical processors of any LPAR; so for example all 13 logical processors are active in LPAR2. The IRD LPAR Vary CPU Management function is in fact incompatible with HiperDispatch and it is therefore disabled when HiperDispatch is active. The polarization weight is reported in the last column ( POW). We can note that: a) Total LPAR weight has not changed; b) Many logical processors have a polarization weight value equal to 0; c) No logical processor has a polarization weight value greater than a) HiperDispatch honours either the LPAR weight or the IRD current weight; it only distributes that weight in order to optimise the number of logical processors to use. The sum of logical processors weights by LPAR gives exactly the same values in the and POW columns. In HiperDispatch mode, the intention is to manage work across fewer logical processors. For example, only one logical processor is needed for LPAR2 to obtain the capacity specified by the IRD current weight so all the other processors have POW values set to 0. b) The logical processors for a LPAR in HiperDispatch mode will be assigned to one of the following groups: high processor share (or high polarity); they will have a target share corresponding to 100% of a physical processor; medium processor share (or medium polarity); they will have a target share greater than 0% and less than 100% of a physical processor; these medium logical processors have the remainder of the LPAR s shares after the allocation of the logical processors with the high share; one or two logical processors (from 0,5 to 1,5 physical processor capacity) will be assigned to this group; low processor share (or low polarity); they will receive a target share corresponding to 0% of a physical processor; these are considered discretionary logical processors which are not needed to allow the LPAR to fully utilise the physical processor resource associated with its weight. 3 As described in the previous chapter, when IRD is active the LPAR weight is considered as the initial weight; a current weight is dynamically set by IRD and used by PR/SM. HiperDispatch Logical Processors and Weight Management 6

7 c) Values reported in the POW column are not the physical processor shares but the logical processor polarization weights. To calculate the physical processor shares the following algorithm has to be used: 1) Sum the weights across all the LPARs; 2) Get the number of physical processors in the shared pool; 3) Calculate the weight value corresponding to 100% of a physical processor dividing the weights sum by the number of physical processors in the shared pool; 4) Divide each logical processor polarization weight ( POW) by the weight value calculated in step 3; the result is the physical processor share. Based on the configuration in Figure 5: 1) Weights sum is 1.000; 2) The number of physical processors in the shared pool is 13; 3) The weight value corresponding to 100% of a physical processor is 76,9 (1.000 / 13); 4) The PCPU SHARE column in Figure 6 shows the physical processor share for each logical processor. SYSPLEX LPARNAME IRD CLUSTER ADDR LPAR CURRENT POW PCPU SHARE SYSPLEX1 LPAR1 CLUSTER % SYSPLEX1 LPAR1 CLUSTER % SYSPLEX1 LPAR1 CLUSTER % SYSPLEX1 LPAR1 CLUSTER % SYSPLEX1 LPAR1 CLUSTER % SYSPLEX1 LPAR1 CLUSTER % SYSPLEX1 LPAR1 CLUSTER % SYSPLEX1 LPAR1 CLUSTER % % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % SYSPLEX1 LPAR2 CLUSTER % % SYSPLEX2 LPAR3 CLUSTER % SYSPLEX2 LPAR3 CLUSTER % % SYSPLEX1 LPAR4 CLUSTER % SYSPLEX1 LPAR4 CLUSTER % SYSPLEX1 LPAR4 CLUSTER % SYSPLEX1 LPAR4 CLUSTER % % SYSPLEX3 LPAR5 CLUSTER % SYSPLEX3 LPAR5 CLUSTER % SYSPLEX3 LPAR5 CLUSTER % SYSPLEX3 LPAR5 CLUSTER % SYSPLEX3 LPAR5 CLUSTER % HiperDispatch Logical Processors and Weight Management 7

8 SYSPLEX3 LPAR5 CLUSTER % % Figure 6 1,300% It s worth noting that the total PCPU SHARE value is 1.300% which corresponds to the total number of physical processors in the shared pool (13). AAP and IIP logical processors and their weights are managed exactly in the same way as standard CPUs. 5 HiperDispatch affinity queues and nodes HiperDispatch provides a more complete and efficient solution than IRD to optimise the number of logical processors used by a LPAR and to maximise the logical processors weights. However the most important benefit provided by HiperDispatch is the fact that, for the first time, z/os and PR/SM communicate and work together, through the polarization weight, in order to redispatch a unit of work to the same physical processor or at least in the same group of physical processors previously used. To accomplish this, the z/os Dispatcher manages work in multiple affinity dispatch queues. All the logical processors associated to the same affinity dispatch queue are considered a logical processor affinity pool. All the logical processors in a logical processor affinity pool have the same polarization weight. In the current z/os HiperDispatch design: there is only one dispatch queue associated to medium polarity logical processors; no more than four high polarity logical processors can be associated with the same affinity dispatch queue; if more than four logical processors are used, z/os creates a new affinity dispatch queue and a new high polarity logical processor affinity pool. PR/SM with z10 establishes affinity nodes consisting of up to four physical processors which correspond to high polarity logical processors affinity pools. In the current HiperDispatch design PR/SM tries to: maintain all the physical processors in the same affinity node on the same book; dispatch a logical processor to the same physical processors previously used or in alternative to a physical processor in the same affinity node; dedicate a physical processor to each high polarity logical processor. 6 HiperDispatch Measurements All the measurements presented in this chapter refers to the SYS4 system running inside LPAR4. The most important new metrics available to control HiperDispatch behaviour are: the logical processor s share of a physical processor (derived from the polarization weight as discussed in chapter 5); HiperDispatch Logical Processors and Weight Management 8

9 the parked time. The logical processor s share of a physical processor has to be considered as a target utilization for PR/SM dispatching. So the logical processors busy may be different from that target depending on running workloads and other LPARs needs. In Figure 7 the SYS4 logical processors share profile is presented. SYSTEM LOGICAL CPU UTILIZATION SHARE SHARE OF PCPU/HOUR - SYS4 - FRI, 30 MAY % 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 1 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 2 95% 95% 95% 75% 69% 65% 80% 66% 78% 95% 77% 74% 56% 56% 56% 56% 63% 95% 95% 95% 3 0% 0% 0% 29% 37% 34% 0% 41% 25% 0% 26% 30% 56% 56% 56% 56% 46% 0% 0% 0% 295% 295% 295% 304% 306% 298% 280% 307% 303% 295% 303% 304% 312% 312% 312% 312% 309% 295% 295% 295% Figure 7 Logical processors 0 and 1 are high polarity while logical processor 2 is medium polarity. Depending on the weight set by IRD, the total LPAR share (in the last row) is less or more than three physical processors. As discussed in Chapter 5, HiperDispatch is designed to assign a minimum of 0,5 up to a maximum of 1,5 logical processors share to the medium polarity group. In this case when the total LPAR share is less than 300%, two high polarity and one medium polarity logical processors are enough, so logical processor 3 is considered low polarity When the total LPAR share is greater than 300%, two high polarity and one medium polarity logical processors are not enough, so logical processor 3 is considered medium polarity. HiperDispatch assigns the same weight to all the LPAR medium polarity logical processors; this doesn t seem to happen always in our report but it s only the effect of averaging the values across a 30 minutes interval. PR/SM considers low polarity logical processors as discretionary processors and it can decide to park them when they are not needed to handle the LPAR workload (not enough load) or are not useful because physical capacity does not exist for PR/SM to dispatch (no available time from other LPARs). In a parked state, discretionary processors do not dispatch work; they are in a long term wait state. The report in Figure 8 shows that only logical processor 3 is parked part of the time. SYSTEM LOGICAL CPU UTILIZATION PARKED PARKED TIME/HOUR - SYS4 - FRI, 30 MAY % 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 1 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 2 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 3 92% 28% 2% 0% 20% 27% 86% 11% 42% 86% 48% 15% 0% 0% 0% 0% 18% 91% 99% 100% Figure 8 In a perfect world we d expect to see the usage of high polarity logical processors close to 100%, the LPAR residual load distributed between medium polarity logical processors and the usage of low polarity logical processors close to 0. Figure 9 shows a more complex situation. HiperDispatch Logical Processors and Weight Management 9

10 SYSTEM LOGICAL CPU UTILIZATION BUSY TIME/HOUR - SYS4 - FRI, 30 MAY % 93% 94% 92% 75% 84% 82% 73% 72% 66% 55% 66% 54% 65% 66% 57% 62% 59% 41% 35% 1 78% 94% 95% 93% 82% 88% 86% 80% 79% 71% 64% 76% 67% 75% 76% 69% 71% 65% 50% 44% 2 72% 64% 57% 65% 66% 69% 74% 65% 69% 69% 65% 74% 62% 65% 64% 62% 66% 67% 53% 45% 3 5% 41% 56% 65% 50% 49% 9% 55% 36% 10% 33% 62% 61% 64% 64% 63% 55% 7% 0% 0% 226% 292% 301% 314% 274% 289% 250% 274% 256% 216% 216% 277% 244% 269% 270% 251% 255% 198% 145% 125% Figure 9 High polarity logical processors busy is more than 90% for a few intervals only. When the LPAR load decreases, especially in the afternoon, the LPAR load seems to be evenly distributed across all the logical processors. The z/os HiperDispatch component seems not to work perfectly on this system. It could be due to: the system level (z/os 1.8 in this case); missing PTFs; the type of workload running on the system. It s important to remember that SRBs in the SYSSTC service class essentially bypasses the z/os HiperDispatch management algorithms. They can execute on any available logical processor. 4 The IIP logical processors analysis is much simpler. As showed in the following reports, logical processor 14 is medium polarity while logical processor 15 is always low polarity; so logical processor 15 is parked all the time. All the load is satisfied by logical processor 14. BUSY SYSTEM LOGICAL IIP UTILIZATION SHARE LIIP SHARE OF PIIP/HOUR - SYS4 - FRI, 30 MAY % 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 15 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% SYSTEM LOGICAL IIP UTILIZATION Figure 10 PARKED LIIP PARKED TIME/HOUR - SYS4 - FRI, 30 MAY % 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% % 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% 100% SYSTEM LOGICAL IIP UTILIZATION Figure 11 LIIP BUSY TIME/HOUR - SYS4 - FRI, 30 MAY % 28% 30% 21% 19% 25% 16% 22% 14% 7% 16% 22% 10% 13% 10% 12% 16% 12% 4% 7% 15 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 0% 14% 28% 30% 21% 19% 25% 16% 22% 14% 7% 16% 22% 10% 13% 10% 12% 16% 12% 4% 7% Figure 12 BUSY 4 See "z/os: Planning Considerations for HiperDispatch Mode" - IBM WSC White Papers - WP HiperDispatch Logical Processors and Weight Management 10

11 7 Conclusions HiperDispatch has been essentially designed to avoid performance degradation and overhead due to L1 and L2 cache misses. HiperDispatch makes z/os and PR/SM communicate and work together in order to re-dispatch a unit of work to the same physical processor or at least in the same group of physical processors previously used HiperDispatch also provides a more complete and efficient solution than IRD to optimise the number of logical processors used by a LPAR and to maximise the logical processors weights. New specific metrics such as the polarization weight and the parked time have been introduced; they have to be fully understood and thoroughly analysed in order to control the HiperDispatch behaviour. All the reports presented here are included in EPV for z/os since version 8. HiperDispatch Logical Processors and Weight Management 11