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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
