)]}'
{"id":"openstack%2Fnova-specs~649882","triplet_id":"openstack%2Fnova-specs~master~I227bae0acc223cfc5e068a23eef825cc264f5376","project":"openstack/nova-specs","branch":"master","topic":"bp/separate-vcpu-into-different-priority-pool","hashtags":[],"change_id":"I227bae0acc223cfc5e068a23eef825cc264f5376","subject":"Separate the vCPUs into different pools based on priority","status":"ABANDONED","created":"2019-04-04 06:07:32.000000000","updated":"2019-05-01 13:52:09.000000000","total_comment_count":101,"unresolved_comment_count":0,"has_review_started":true,"meta_rev_id":"8bac38e970753155a6ac619137b1561dffd1c4b9","_number":649882,"virtual_id_number":649882,"owner":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"actions":{},"labels":{"Verified":{"recommended":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"all":[{"date":"2019-04-22 04:17:18.000000000","_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"_account_id":10068,"name":"Welcome, new contributor!","username":"welcome-message"},{"date":"2019-04-25 22:20:43.000000000","_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":1,"date":"2019-04-20 03:39:55.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"}],"values":{"-2":"Fails","-1":"Doesn\u0027t seem to work"," 0":"No score","+1":"Works for me","+2":"Verified"},"description":"","value":1,"default_value":0,"optional":true},"Code-Review":{"rejected":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"all":[{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},{"value":0,"permitted_voting_range":{"min":-2,"max":2},"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":10068,"name":"Welcome, new contributor!","username":"welcome-message"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":-1,"date":"2019-04-22 02:32:19.000000000","permitted_voting_range":{"min":-1,"max":1},"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"value":-2,"date":"2019-04-25 22:19:10.000000000","permitted_voting_range":{"min":-2,"max":2},"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"}],"values":{"-2":"Do not merge","-1":"This patch needs further work before it can be merged"," 0":"No score","+1":"Looks good to me, but someone else must approve","+2":"Looks good to me (core reviewer)"},"description":"","default_value":0,"optional":true},"Workflow":{"all":[{"value":0,"permitted_voting_range":{"min":-1,"max":0},"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"_account_id":10068,"name":"Welcome, new contributor!","username":"welcome-message"},{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"value":0,"permitted_voting_range":{"min":-1,"max":1},"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"}],"values":{"-1":"Work in progress"," 0":"Ready for reviews","+1":"Approved"},"description":"","default_value":0,"optional":true},"Review-Priority":{"all":[{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":10068,"name":"Welcome, new contributor!","username":"welcome-message"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"value":0,"permitted_voting_range":{"min":0,"max":2},"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"value":0,"permitted_voting_range":{"min":0,"max":1},"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"}],"values":{" 0":"Default Priority","+1":"Contributor Review Promise","+2":"Core Review Promise"},"description":"","default_value":0,"optional":true}},"removable_reviewers":[],"reviewers":{"REVIEWER":[{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},{"_account_id":10068,"name":"Welcome, new contributor!","username":"welcome-message"},{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"}]},"pending_reviewers":{},"reviewer_updates":[{"updated":"2019-04-04 06:07:46.000000000","updated_by":{"_account_id":10068,"name":"Welcome, new contributor!","username":"welcome-message"},"reviewer":{"_account_id":10068,"name":"Welcome, new contributor!","username":"welcome-message"},"state":"REVIEWER"},{"updated":"2019-04-09 13:24:41.000000000","updated_by":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"reviewer":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"state":"REVIEWER"},{"updated":"2019-04-09 17:32:32.000000000","updated_by":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"reviewer":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"state":"REVIEWER"},{"updated":"2019-04-20 03:39:55.000000000","updated_by":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"reviewer":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"state":"REVIEWER"},{"updated":"2019-04-22 02:32:19.000000000","updated_by":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"reviewer":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"state":"REVIEWER"},{"updated":"2019-04-25 22:19:10.000000000","updated_by":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"reviewer":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"state":"REVIEWER"},{"updated":"2019-04-25 22:20:43.000000000","updated_by":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"reviewer":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"state":"REVIEWER"}],"messages":[{"id":"f851d5224ba12289ddd18a39f8ca98c16cf394b0","author":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"date":"2019-04-04 06:07:32.000000000","message":"Uploaded patch set 1.","accounts_in_message":[],"_revision_number":1},{"id":"ad14b2067dd34de06352388cbc3f635a50bbe3f9","author":{"_account_id":10068,"name":"Welcome, new contributor!","username":"welcome-message"},"date":"2019-04-04 06:07:46.000000000","message":"Patch Set 1:\n\nThank you for your first contribution to OpenStack.\n\nYour patch will now be tested automatically by OpenStack testing frameworks\nand once the automatic tests pass, it will be reviewed by other friendly\ndevelopers. They will give you feedback and may require you to refine it.\n\nPeople seldom get their patch approved on the first try, so don\u0027t be\nconcerned if requested to make corrections. Feel free to modify your patch\nand resubmit a new change-set.\n\nPatches usually take 3 to 7 days to be reviewed so be patient and be\navailable on IRC to ask and answer questions about your work. Also it\ntakes generally at least a couple of weeks for cores to get around to\nreviewing code. The more you participate in the community the more\nrewarding it is for you. You may also notice that the more you get to know\npeople and get to be known, the faster your patches will be reviewed and\neventually approved. Get to know others and become known by doing code\nreviews: anybody can do it, and it\u0027s a great way to learn the code base.\n\nThanks again for supporting OpenStack, we look forward to working with you.\n\nIRC: https://wiki.openstack.org/wiki/IRC\nWorkflow: https://docs.openstack.org/infra/manual/developers.html\nCommit Messages: https://wiki.openstack.org/wiki/GitCommitMessages","accounts_in_message":[],"_revision_number":1},{"id":"273fd3d7dade458eaaad978df5f3db14748373bc","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-04-04 06:26:07.000000000","message":"Patch Set 1: Verified-1\n\nBuild failed (check pipeline).  For information on how to proceed, see\nhttp://docs.openstack.org/infra/manual/developers.html#automated-testing\n\n\n- openstack-tox-docs http://logs.openstack.org/82/649882/1/check/openstack-tox-docs/9b9be89/ : FAILURE in 7m 16s\n- openstack-tox-pep8 http://logs.openstack.org/82/649882/1/check/openstack-tox-pep8/77f9016/ : SUCCESS in 7m 58s","accounts_in_message":[],"_revision_number":1},{"id":"b8661ab6eb0b238969f5dbb8867325858b032597","author":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"date":"2019-04-04 07:31:10.000000000","message":"Uploaded patch set 2.","accounts_in_message":[],"_revision_number":2},{"id":"d90a6d5f0b0da3f0e706c32e736560bca8deff8b","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-04-04 07:46:17.000000000","message":"Patch Set 2: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/82/649882/2/check/openstack-tox-docs/79ce4bf/html/ : SUCCESS in 9m 20s\n- openstack-tox-pep8 http://logs.openstack.org/82/649882/2/check/openstack-tox-pep8/ae24234/ : SUCCESS in 13m 39s","accounts_in_message":[],"_revision_number":2},{"id":"4bfc2ecb6df009c700f82a0193e68174975aee8c","author":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"date":"2019-04-09 13:13:10.000000000","message":"Uploaded patch set 3.","accounts_in_message":[],"_revision_number":3},{"id":"7e5189e32afafada47f8cc5a2d16c0f8a449a910","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-04-09 13:26:34.000000000","message":"Patch Set 3: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/82/649882/3/check/openstack-tox-docs/a90f571/html/ : SUCCESS in 8m 01s\n- openstack-tox-pep8 http://logs.openstack.org/82/649882/3/check/openstack-tox-pep8/368eaaa/ : SUCCESS in 5m 00s","accounts_in_message":[],"_revision_number":3},{"id":"6b75cdcb82fc0737913caad465f2c26e60b91911","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-04-09 14:19:29.000000000","message":"Patch Set 3: Code-Review-1\n\n(10 comments)","accounts_in_message":[],"_revision_number":3},{"id":"c710524e882d77eeb80ff2fb52a3020ea3a13e23","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-04-09 16:20:20.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"9d901fe17f69d4eed75483b34f224390c2f59c5b","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-04-09 17:32:32.000000000","message":"Patch Set 3: Code-Review-1\n\n(20 comments)","accounts_in_message":[],"_revision_number":3},{"id":"617648928b76b662e4799470360c606d5ad6a6f2","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-04-09 17:39:00.000000000","message":"Patch Set 3:\n\n(4 comments)\n\ni am concerned this will conflict with several other efforts and \nwill make the cpu pinning and numa code even more complex. i would be concerend making this change without a lot of testing.","accounts_in_message":[],"_revision_number":3},{"id":"3923624059445dd2e16bf0c000c23a1edd7f9bef","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-04-09 17:45:05.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"5df2e1c380cd0043b64510730d20135ee4eb2d88","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-04-10 06:25:29.000000000","message":"Patch Set 3:\n\n(21 comments)\n\nSean, thanks for all those good comments","accounts_in_message":[],"_revision_number":3},{"id":"4d435953eca8ab1a1f48714663623e45184b7869","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-04-10 08:36:49.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"ecdae54c0676c8205cf11e9f19ee8eac8b281d82","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-04-10 08:58:03.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"791d5b0089372fc37db6f291c515237022e65a3f","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-04-10 09:39:16.000000000","message":"Patch Set 3:\n\n(11 comments)\n\nby the way im more ok with this proposal after a nights sleep on it.\n\nif we tweek a few things i think it could be useful but i also think its somewhat complex hence it will need good testing which i think we can provide.","accounts_in_message":[],"_revision_number":3},{"id":"bd347e8bbe11ef80b513f620bb5eaed54386d0f2","author":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"date":"2019-04-10 10:17:31.000000000","message":"Patch Set 3:\n\n(12 comments)\n\n@Alex Xu @sean mooney, Updated and thanks for review.","accounts_in_message":[],"_revision_number":3},{"id":"19cf424285ad9f86778d415ce496f27e222291bb","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-04-10 12:40:46.000000000","message":"Patch Set 3:\n\n(6 comments)","accounts_in_message":[],"_revision_number":3},{"id":"9e3b02dbd35aa14694dd732c55180cb57218e472","author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"date":"2019-04-10 13:30:21.000000000","message":"Patch Set 3: Code-Review-1\n\n(2 comments)\n\nStrong -1 from me.\n\nThis is too complicated and adds a bunch more code and micro-optimizations for a very small number of non-cloudy use cases (basically, NFV and arguably HPC). Plus, the entire use case can we implemented with the proposal already established in the cpu-resource-tracking spec.\n\nThe way proposed in the cpu-resource-tracking spec of having two distinct pools for shared and dedicated CPUs is simpler and fits with the resource tracking model already present in placement, doesn\u0027t add a bunch of complex traits, and doesn\u0027t require any new fields to the awful InstanceNUMATopology object.\n\nBasically, if we go with the cpu-resource-tracking spec\u0027s proposal, the operator would set the cpu_shared_set to the host physical CPUs that would be used for \"low-priority\" guest vCPUs. The operator would set cpu_dedicated_set to the host physical CPUs to be used for the \"high-priority\" guest vCPUs (that will be pinned to a host physical CPU).\n\nThe operator would then -- in their configuration management system of choice, not as yet another CONF option in Nova or yet another trait/extra_spec -- set the CPU frequency governor for the host physical CPUs in the cpu_shared_set and cpu_dedicated_set to the governor they wished to use for low and high priority CPUs, respectively.\n\n-jay","accounts_in_message":[],"_revision_number":3},{"id":"4ef5deccd29778d9a9b93cba4e2e690a773b977a","author":{"_account_id":11604,"name":"sean mooney","email":"smooney@redhat.com","username":"sean-k-mooney"},"date":"2019-04-10 13:55:51.000000000","message":"Patch Set 3:\n\n(4 comments)","accounts_in_message":[],"_revision_number":3},{"id":"73857de3e541659d1bca5ae606e29033ec605b4c","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-04-11 08:05:28.000000000","message":"Patch Set 3:\n\n@Jay, Sir, thanks for your comment!\n\nSo let us talk about the common usecase first, like a host is only running dedicated cpu or only running shared cpu. This is a suggestion we give to our user today from Nova. For this case, we can change some of pCPUs running at high frequency and some of pCPUs running at low frequency. That means the user needn\u0027t to buy two kinds of machine for two kinds of workload(frequency sensitive and non-frequency sensitive), even for one of the workloads is very rare in the cloud. They can mix these two kinds of workloads into one type machine to save money. So we aren\u0027t focusing on the case mix the shared and dedicated cpu in the same host. We are focusing on the case we may have different requirement on a set of dedicated cpus or a set of shared cpus. For the case mix the shared and dedicated cpu on the same host, I don\u0027t think it is a common case, in the today. The most common case is people only running dedicated vcpus on a set of hosts, and them running shared vcpus on another set of hosts.\n\nThere is also a question for mix the shared and dedicated cpu on the same host, why people want to that, what is the usecase behind that? Even with your spec, the shared cpu still can float on the dedicated cpus, that is a problem. But that is a question for your spec. It is really not a case we are focusing on this spec.\n\nAlso for the NFV....if you said it is non-cloudy and a small set of usecase, I will say, I only saw three usecases in your spec, two of them are NFV, one is for edge, non of them are \u0027typical cloud\u0027 :)\n\nFor the complexity, yes, I see, Sean also has same concern. To be honest, I have same concern when we begin to do this proposal, after some PoC, I can see it isn\u0027t complex like I imagine. so I guess the only thing we can do is bring the code up here asap. Then we will see how was looks like.","accounts_in_message":[],"_revision_number":3},{"id":"bf048c7cf4852359387a7a0c336ddb36ab823a0e","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-04-11 09:35:14.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"07d004f68dad13c01e8532c0cde0f94545955245","author":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"date":"2019-04-11 10:24:35.000000000","message":"Patch Set 3:\n\n(2 comments)\n\n\u003e (2 comments)\n \u003e \n \u003e Strong -1 from me.\n \u003e \n \u003e This is too complicated and adds a bunch more code and\n \u003e micro-optimizations for a very small number of non-cloudy use cases\n \u003e (basically, NFV and arguably HPC). Plus, the entire use case can we\n \u003e implemented with the proposal already established in the\n \u003e cpu-resource-tracking spec.\n \u003e \n \u003e The way proposed in the cpu-resource-tracking spec of having two\n \u003e distinct pools for shared and dedicated CPUs is simpler and fits\n \u003e with the resource tracking model already present in placement,\n \u003e doesn\u0027t add a bunch of complex traits, and doesn\u0027t require any new\n \u003e fields to the awful InstanceNUMATopology object.\n \u003e \n \u003e Basically, if we go with the cpu-resource-tracking spec\u0027s proposal,\n \u003e the operator would set the cpu_shared_set to the host physical CPUs\n \u003e that would be used for \"low-priority\" guest vCPUs. The operator\n \u003e would set cpu_dedicated_set to the host physical CPUs to be used\n \u003e for the \"high-priority\" guest vCPUs (that will be pinned to a host\n \u003e physical CPU).\n \u003e \n \u003e The operator would then -- in their configuration management system\n \u003e of choice, not as yet another CONF option in Nova or yet another\n \u003e trait/extra_spec -- set the CPU frequency governor for the host\n \u003e physical CPUs in the cpu_shared_set and cpu_dedicated_set to the\n \u003e governor they wished to use for low and high priority CPUs,\n \u003e respectively.\n \u003e \n \u003e -jay\n\nHi Jay,\n\nThanks for comments. Regarding the use cases and problem statement paragraphs, I\u0027ll refine them by bringing more use cases we have met in our experience during enabling data center and cloud customers.\n\nFollowing two paragraphs are also the \u0027Problem Statement\u0027 of this spec that we\u0027d like to update:\n\nThe Linux per-CPU frequency scaling functionality and its underlying technologies are more and more expected by the infrastructure provider (refers to physical server provider inside a data center/cloud company) from the perspective of reducing the physical machine type in the whole cloud. \n\nWhile Nova does not provide the function of changing machine type through software configuration, in this spec, particularly, what we proposed is changing the CPU frequency to change machine type,  simplifying the selection of physical server machine type.\n\nOne use case is: \nAs I know, some workload (search engine) has such kind of component which is quite frequency sensitive and expecting the CPU frequency to be as high as possible; The other parts of the workloads are friendly to core scalability, which performance could be enhanced by more cores. Since these two types of workload are both key workload, have critical service quality requirement, they are not expected to be deployed on \u0027shared\u0027 CPUs. With this spec, we could\nlet the frequency sensitive search engine component to enjoy more TDP/power quota to have a higher frequency and the other components\u0027 service quality could be ensured by more the relatively \u0027low\u0027 frequency cores. Otherwise, the user has to deploy two types of physical server machine, one with high frequency CPU another equipped with normal type CPU,  this is not user preferred in comparing with the solution of allocating some high frequency cores dedicated to the frequency sensitive component.\n\nIsolating prioritized workloads by \u0027shared\u0027 and \u0027dedicated\u0027 CPU groups do not help in this case, because most components of the search engine workload are key components, search engine\u0027s end user cannot bear the long search query latency. The difference is these components have different frequency/core count scalability. The requirement for \u0027dedicated\u0027 CPU but with different CPU frequency tier is quite common.\n\nAfter all, we are considering the use cases and problem statement from the point of CPU manufacturer, that is what we experienced in our job.\n\nThanks\nHuaqiang","accounts_in_message":[],"_revision_number":3},{"id":"c18cb79aa1327bcd7159af32cdf20831b2ab937e","author":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"date":"2019-04-11 10:35:27.000000000","message":"Patch Set 3:\n\n(1 comment)","accounts_in_message":[],"_revision_number":3},{"id":"ee9a3ccb9df764f679ebc728b2d15f700d7ab38a","author":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"date":"2019-04-12 12:06:02.000000000","message":"Patch Set 3:\n\n(3 comments)","accounts_in_message":[],"_revision_number":3},{"id":"724dbeb398a64010567d4acc4882be97de488c8e","author":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"date":"2019-04-20 03:24:01.000000000","message":"Uploaded patch set 4.","accounts_in_message":[],"_revision_number":4},{"id":"9c3d720eb8bda838ae7df86fa5a20d7a105a332f","author":{"_account_id":22348,"name":"Zuul","username":"zuul","tags":["SERVICE_USER"]},"date":"2019-04-20 03:39:55.000000000","message":"Patch Set 4: Verified+1\n\nBuild succeeded (check pipeline).\n\n- openstack-tox-docs http://logs.openstack.org/82/649882/4/check/openstack-tox-docs/c47b9f2/html/ : SUCCESS in 7m 28s\n- openstack-tox-pep8 http://logs.openstack.org/82/649882/4/check/openstack-tox-pep8/21e1d50/ : SUCCESS in 4m 39s","accounts_in_message":[],"_revision_number":4},{"id":"f112d6ed784c7bfbc038046ddbe657e615ab140e","author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"date":"2019-04-22 02:32:19.000000000","message":"Patch Set 4: Code-Review-1\n\nRepeating from revision 3 comment, since nothing of substance has changed about this spec/proposal:\n\nThis is too complicated and adds a bunch of code and micro-optimizations for a very small number of use cases.\n\nIf we go with the cpu-resource-tracking spec\u0027s proposal, the operator would set the cpu_shared_set to the host physical CPUs that would be used for \"low-priority\" guest vCPUs. The operator would set cpu_dedicated_set to the host physical CPUs to be used for the \"high-priority\" guest vCPUs (that will be pinned to a host physical CPU).\n\nThe operator would then set the CPU frequency governor for the host physical CPUs in the cpu_shared_set and cpu_dedicated_set to the governor they wished to use for low and high priority CPUs, respectively.\n\n-jay","accounts_in_message":[],"_revision_number":4},{"id":"ea3c3f47bd986142ca98a98af3b6a8dd2e66d944","author":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"date":"2019-04-22 04:17:18.000000000","message":"Patch Set 4:\n\nHi Jay,\n\nThank for review.\n\nI got your concerns about two aspects. First is what the spec is proposing is too complicated and code might be huge, we are preparing the POC code and we don\u0027t find too many changes, how about let\u0027s submit the POC code as soon as possible and please make a code review then and we can simplify the code as the spec based on that.\n\nThe second opinion is the spec only covers a small number of use cases and the functionality could be covered by the \u0027cpu-resource-tracking\u0027 spec. We really met a lot of cloud/data center customers who expect to apply fine-grained control over CPU and deploy muliti-workloads with different workload characterization on same compute node.\n\nWe met a request from Chinese search giant for their key business that deploying latency sensitive workloads on same host, part of the workloads\u0027 performance could satisfying improvement through core scaling, but some of workloads, especially the ones tackling complex logic rules, have bad core scaling behavior but pretty good frequency scaling behavior. It is hoped these workloads could be deployed on a same host with the benefit of processing the same data set and avoiding huge data transfer between hosts. This request could be satisfied if the host\u0027s CPU could be partitioned with high performance CPUs at the cost of low performance CPUs, the frequency sensitive workload could be deployed with high performance CPUs and core sensitive workloads\u0027 performance could be met by adding more cores, the benefit is all workloads could share the data set on same  host which reduces a lot of traffic between hosts and improves workload latency a lot.\n\nAll above vCPUs should be 1:1 pinned to host CPUs since it is the key workload and has a critical latency limit at the requirement of good user experience. So what is this spec proposing is an enhancement to \u0027cpu-resource-tracking\u0027 spec.\n\nEnd users want flexible configuration over the control of CPU inside resources and let their host in the cloud platform could be possible to fit all kinds of workloads with different characterization towards frequency and core number. \n\nCPU vendors are aware of the needs for assigning more resources for partial CPU inside a physical processor, such as creating CPUs having high frequency than rest cores, creating CPUs having more L3 caches than average, creating CPUs enjoying more and guaranteed memory bandwidth. All these technologies could not be covered by  the \u0027cpu-resource-tracking\u0027 spec.\n\nReallocating CPU hardware resources inside a processor (the technologies are Intel Speed Select introduced since recent CascadeLake, Cache Allocation and Memory Allocation introduced since Haswell) and re-characterize physical server machines through software are the trend. Data center provider could be able to change the physical host\u0027 characterization, make it possible to deploy one (or fewer) type of server machines for all kind of workloads. As we stated above, without these technologies, there might need a host aggregate with high frequency CPU hosts, other host aggregates with normal frequency CPU hosts. \n\nWe do think nova need this feature to support the hardware\u0027s capability of configuring host through a software way, creating higher and guaranteed frequency CPUs for high performance workload (covered in this spec), creating bigger and guaranteed L3 cache/memory dedicated for high performance workload (maybe be introduced afterward).\n\nSincerely \nHuaChang","accounts_in_message":[],"_revision_number":4},{"id":"da849f172e54df0a32bbb55160de0e672aa68095","author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"date":"2019-04-22 14:19:04.000000000","message":"Patch Set 4:\n\n\u003e We met a request from Chinese search giant for their key business\n \u003e that deploying latency sensitive workloads on same host, part of\n \u003e the workloads\u0027 performance could satisfying improvement through\n \u003e core scaling, but some of workloads, especially the ones tackling\n \u003e complex logic rules, have bad core scaling behavior but pretty good\n \u003e frequency scaling behavior. It is hoped these workloads could be\n \u003e deployed on a same host with the benefit of processing the same\n \u003e data set and avoiding huge data transfer between hosts. This\n \u003e request could be satisfied if the host\u0027s CPU could be partitioned\n \u003e with high performance CPUs at the cost of low performance CPUs, the\n \u003e frequency sensitive workload could be deployed with high\n \u003e performance CPUs and core sensitive workloads\u0027 performance could be\n \u003e met by adding more cores, the benefit is all workloads could share\n \u003e the data set on same  host which reduces a lot of traffic between\n \u003e hosts and improves workload latency a lot.\n \u003e \n \u003e All above vCPUs should be 1:1 pinned to host CPUs since it is the\n \u003e key workload and has a critical latency limit at the requirement of\n \u003e good user experience. So what is this spec proposing is an\n \u003e enhancement to \u0027cpu-resource-tracking\u0027 spec.\n\nWhy doesn\u0027t Baidu just use baremetal if this is the kind of micro-optimization and level of hyper-tuning that they require?\n\nI\u0027m asking a serious question, here. Why should the rest of Nova suffer from increased complexity, increased bug surface area and potential code rot when there are existing solutions to this problem: use baremetal (with Ironic even!) and let the tenant over-optimize and micro-configure their resources themselves.\n\nI have the same question on the RMD specs, frankly.\n\nI\u0027m not trying to be negative, but there is a limit to Nova\u0027s scope, and there is a point to having Nova be an *abstraction* over hardware. Is Nova nothing more than a Python library that basically passes through hardware and operating-system level configuration knobs to the user? Fundamentally, Nova is an abstraction layer above the hypervisor and the hardware that is intended to *simplify* things for a user of the cloud.\n\nI fail to see how these specs are going to simplify anything, which is why I\u0027m pushing back hard on them.\n\nSorry for being so harsh and blunt about it. I\u0027d like to stress that my words are not a personal attack on you or your colleagues. Please don\u0027t take this criticism personally.\n\nBest,\n\n-jay","accounts_in_message":[],"_revision_number":4},{"id":"0c6575f401d05134b9e14a8858dcd6504649355e","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-04-25 22:19:10.000000000","message":"Patch Set 4: Code-Review-2\n\nWe are interested in Jay\u0027s proposal,  so turn to review https://review.opendev.org/555081.","accounts_in_message":[],"_revision_number":4},{"id":"eac6e3a45c81313586bbbe16db097ea2a81cd651","author":{"_account_id":14070,"name":"Eric Fried","email":"openstack@fried.cc","username":"efried"},"date":"2019-04-25 22:20:43.000000000","message":"Patch Set 4:\n\n@Alex, should I keep \"Separate the CPU into different pool based on priority\" on the PTG agenda to iron out the details?","accounts_in_message":[],"_revision_number":4},{"id":"60bcfbc8a5fab09db66bf7c5d50a63ba61af0685","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-04-26 00:03:17.000000000","message":"Patch Set 4:\n\nI just remove it, if we have something want to say, we can discuss on the timeframe for the spec standard cpu resource tracking","accounts_in_message":[],"_revision_number":4},{"id":"64c843fff4cd0e6ed1288b64108367fff9579ce6","author":{"_account_id":5754,"name":"Alex Xu","email":"hejie.xu@intel.com","username":"xuhj"},"date":"2019-05-01 13:52:09.000000000","message":"Abandoned","accounts_in_message":[],"_revision_number":4}],"current_revision_number":4,"current_revision":"1609e1a819fe20e83e480a3f515d928f8fa3e695","revisions":{"47fc16b78580b4bdb419edf63fda8509aa557032":{"kind":"REWORK","_number":1,"created":"2019-04-04 06:07:32.000000000","uploader":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"ref":"refs/changes/82/649882/1","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/82/649882/1","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/1 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/1 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/1 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/1"}}},"commit":{"parents":[{"commit":"a2a3d7203489b85cf519259d9a4eca5ed439aa71","subject":"Re-propose emulated virtual TPM spec to train","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/a2a3d7203489b85cf519259d9a4eca5ed439aa71"}]}],"author":{"name":"Wang Huaqiang","email":"huaqiang.wang@intel.com","date":"2019-04-04 01:38:19.000000000","tz":480},"committer":{"name":"Wang Huaqiang","email":"huaqiang.wang@intel.com","date":"2019-04-04 05:10:36.000000000","tz":480},"subject":"Separate the vCPUs into different pools based on priority","message":"Separate the vCPUs into different pools based on priority\n\nIntroduce prioritized CPU pool based on kernel \u0027cpufreq\u0027 module. Instance,\nthen, will be possible to apply vCPU based on priority.\n\nChange-Id: I227bae0acc223cfc5e068a23eef825cc264f5376\nBlueprint: separate-vcpu-into-different-priority-pool\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/47fc16b78580b4bdb419edf63fda8509aa557032"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/47fc16b78580b4bdb419edf63fda8509aa557032"}]},"branch":"refs/heads/master"},"6ea498e898212d5dfb9cca8b69ed1ebd2283553e":{"kind":"REWORK","_number":2,"created":"2019-04-04 07:31:10.000000000","uploader":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"ref":"refs/changes/82/649882/2","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/82/649882/2","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/2 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/2 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/2 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/2"}}},"commit":{"parents":[{"commit":"a2a3d7203489b85cf519259d9a4eca5ed439aa71","subject":"Re-propose emulated virtual TPM spec to train","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/a2a3d7203489b85cf519259d9a4eca5ed439aa71"}]}],"author":{"name":"Wang Huaqiang","email":"huaqiang.wang@intel.com","date":"2019-04-04 01:38:19.000000000","tz":480},"committer":{"name":"Wang Huaqiang","email":"huaqiang.wang@intel.com","date":"2019-04-04 07:29:49.000000000","tz":480},"subject":"Separate the vCPUs into different pools based on priority","message":"Separate the vCPUs into different pools based on priority\n\nIntroduce prioritized CPU pool based on kernel \u0027cpufreq\u0027 module. Instance,\nthen, will be possible to apply vCPU based on priority.\n\nChange-Id: I227bae0acc223cfc5e068a23eef825cc264f5376\nBlueprint: separate-vcpu-into-different-priority-pool\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/6ea498e898212d5dfb9cca8b69ed1ebd2283553e"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/6ea498e898212d5dfb9cca8b69ed1ebd2283553e"}]},"branch":"refs/heads/master"},"abd2ba916dfe93e61d24d7f652fcf99db2223e11":{"kind":"REWORK","_number":3,"created":"2019-04-09 13:13:10.000000000","uploader":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"ref":"refs/changes/82/649882/3","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/82/649882/3","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/3 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/3 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/3 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/3"}}},"commit":{"parents":[{"commit":"a2a3d7203489b85cf519259d9a4eca5ed439aa71","subject":"Re-propose emulated virtual TPM spec to train","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/a2a3d7203489b85cf519259d9a4eca5ed439aa71"}]}],"author":{"name":"Wang Huaqiang","email":"huaqiang.wang@intel.com","date":"2019-04-04 01:38:19.000000000","tz":480},"committer":{"name":"Wang Huaqiang","email":"huaqiang.wang@intel.com","date":"2019-04-09 13:10:47.000000000","tz":480},"subject":"Separate the vCPUs into different pools based on priority","message":"Separate the vCPUs into different pools based on priority\n\nIntroduce prioritized CPU pool based on kernel \u0027cpufreq\u0027 module. Instance,\nthen, will be possible to apply vCPU based on priority.\n\nChange-Id: I227bae0acc223cfc5e068a23eef825cc264f5376\nBlueprint: separate-vcpu-into-different-priority-pool\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/abd2ba916dfe93e61d24d7f652fcf99db2223e11"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/abd2ba916dfe93e61d24d7f652fcf99db2223e11"}]},"branch":"refs/heads/master"},"1609e1a819fe20e83e480a3f515d928f8fa3e695":{"kind":"REWORK","_number":4,"created":"2019-04-20 03:24:01.000000000","uploader":{"_account_id":30209,"name":"Huaqiang","email":"huaqiang.wang@intel.com","username":"Huaqiang.Wang"},"ref":"refs/changes/82/649882/4","fetch":{"anonymous http":{"url":"https://review.opendev.org/openstack/nova-specs","ref":"refs/changes/82/649882/4","commands":{"Checkout":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/4 \u0026\u0026 git checkout FETCH_HEAD","Cherry Pick":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/4 \u0026\u0026 git cherry-pick FETCH_HEAD","Format Patch":"git fetch https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/4 \u0026\u0026 git format-patch -1 --stdout FETCH_HEAD","Pull":"git pull https://review.opendev.org/openstack/nova-specs refs/changes/82/649882/4"}}},"commit":{"parents":[{"commit":"a2a3d7203489b85cf519259d9a4eca5ed439aa71","subject":"Re-propose emulated virtual TPM spec to train","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/a2a3d7203489b85cf519259d9a4eca5ed439aa71"}]}],"author":{"name":"Wang Huaqiang","email":"huaqiang.wang@intel.com","date":"2019-04-04 01:38:19.000000000","tz":480},"committer":{"name":"Wang Huaqiang","email":"huaqiang.wang@intel.com","date":"2019-04-19 16:41:29.000000000","tz":480},"subject":"Separate the vCPUs into different pools based on priority","message":"Separate the vCPUs into different pools based on priority\n\nThis specification is for nova to be aware of the CPUs that has a performance\npriority and manage guest instance upon these CPUs.\n\nChange-Id: I227bae0acc223cfc5e068a23eef825cc264f5376\nBlueprint: separate-vcpu-into-different-priority-pool\n","web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/1609e1a819fe20e83e480a3f515d928f8fa3e695"}],"resolve_conflicts_web_links":[{"name":"gitea","tooltip":"Open in GitWeb","url":"https://opendev.org/openstack/nova-specs/commit/1609e1a819fe20e83e480a3f515d928f8fa3e695"}]},"branch":"refs/heads/master"}},"requirements":[],"submit_records":[],"submit_requirements":[]}