daviftorres commented on PR #12330:
URL: https://github.com/apache/cloudstack/pull/12330#issuecomment-3921894122

   > Currently, all constrained offerings have the CPU value set to 0. With 
this setting, KVM and VMware do not complain and do not throttle CPU 
performance.
   > 
   > However, all custom offerings require a positive CPU value; otherwise, 
they do not work.
   > 
   > I am not sure what the best approach is to address this issue, as my goal 
is to achieve the best possible performance per core, regardless of the 
underlying processor.
   
   Hey everyone, I’m not sure where we currently stand on this.
   
   As I mentioned before, CPUs have both base and burst clock speeds. Using `0` 
as the clock value for the constrained offering is consistent with `libvirt`, 
where it represents an unlimited setting.
   
   The limitation is that we can only configure based on CPU’s base clock, not 
the burst clock. This could unintentionally:
   
   1. Throttled performance of guest instances, or
   2. Prevented instances from starting if no host satisfies the allocation 
criteria.
   
   For (1): I’m not completely sure this is happening, but when I run `virsh 
dumpxml`, I can see the clock value expressed in Hz. Its presence suggests that 
it is intended to be enforced, likely through throttling.
   
   For (2): I’ve previously observed that when an offering specifies a clock 
speed that falls within the CPU’s burstable range but exceeds its baseline 
frequency, the instance fails to start.
   
   When using `0` for the clock, `dumpxml` returns:
   ```
     <vcpu placement='static'>8</vcpu>
   ```
   
   When using positive values, it returns:
   ```
     <vcpu placement='static'>24</vcpu>
     <cputune>
       <shares>966</shares>
       <period>10000</period>
       <quota>8700</quota>
     </cputune>
   ```
   Or
   ```
     <vcpu placement='static'>8</vcpu>
     <cputune>
       <shares>866</shares>
     </cputune>
   ```
   
   Am I miss understanding the issue?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to