Open Stack

On 06/30/2015 07:42 AM, ChangBo Guo wrote:
> CPU frequency  is an import performance parameter,  currently  nova
> drivers just  report cpu_info without frequency.   we stored the compute
> node cpu_info in database with colum compute_nodes.cpu_info,  we can add
> the frequency  easily.
> 
> The usage of  cpu frequency  I  can think is used to schedule to meet
> applications which need high frequency.  add a frequency based filter ?
> if we need this , I would like to propose  a spec for this .
> 

Would it be possible to give more details on the type of app that will
have this _specific_ requirement.

I don't think I have all the details in my head, but it seems to me that
the frequency of the hypervisor CPU is just not something that carries
enough information for users about how most applications will perform. I
would imagine they would either want "the fastest" or some specialized
HW for specific applications.

> 
> There are two steps to leverage cpu frequency:
> 1.  report cpu frequency  and record the value,  nova hypervisor-show
> will include the value .
> 
> 2.  filter compute nodes based  cpu frequency.
>     add a new scheduler filter to do that
> 
> before I start to do these stuff.  I would like to your  input .
> 
> Do we need leverage CPU frequency  in Nova ?
> if yes, do we need a new filter  or  leverage existing filter to use
> frequency ?
> 

I don't think we do personally - but I may not understand what problem
this is trying to solve.

But even if we do - the most important thing IMHO would be _how_ to
expose it to users (do we allow them to request a minimum frequency, or
a specific one or something else). API contract is extremely important
here because we want to make sure that we are exposing the right
semantics for users - as we would want this to be usable to as big a
group of people as possible.

If it's just about having a high performance tier - can we do this with
host aggregates and flavors? These are the questions we want to answer
first IMHO.

N.

> -- 
> ChangBo Guo(gcb)
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>