)]}'
{"specs/juno/virt-driver-cpu-pinning.rst":[{"author":{"_account_id":1501,"name":"Phil Day","email":"philip.day@hp.com","username":"philip-day"},"change_message_id":"d1aa7de277de79e5de9fb257e8161dff4e1431bc","unresolved":false,"context_lines":[{"line_number":35,"context_line":"The flavour extra specs will be enhanced to support two new parameters"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"* hw_cpu:policy\u003dshared|dedicated"},{"line_number":38,"context_line":"* hw_cpu:threads_policy\u003davoid|separate|prefer"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"If the policy is set to \u0027shared\u0027 no change will be made compared to the current"},{"line_number":41,"context_line":"default guest CPU placement policy. The guest vCPUs will be allowed to freely"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_dd2a8b8f","line":38,"updated":"2014-05-23 10:23:35.000000000","message":"This model seems to assume that the maximum compute capacity exposed by a vCPU in the flavor is always on pCPU of teh host that its gets scheduled onto - and in practice that\u0027s not a great model.\n\nThe extensible resource tracker is, amongst other things, designed to enable flavors to express both the width (vCPUs) and capacity (In some arbitary normalised units) of CPU performance of a flavor - so that it becomes possible to express a flavor that uses (for example) 25% of one pCPU of some server type.\n\nSo I can still see a use even here for expressing that the user wants dedicated rather than over-committed capacity - but the way of counting that in the scheduler needs to be more complex that just counting vCPUs.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":6932,"name":"Adrian Hoban","email":"adrian.hoban@intel.com","username":"adrian-hoban"},"change_message_id":"671a8d67b63f8c2544201c877d0d4168f4317077","unresolved":false,"context_lines":[{"line_number":35,"context_line":"The flavour extra specs will be enhanced to support two new parameters"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"* hw_cpu:policy\u003dshared|dedicated"},{"line_number":38,"context_line":"* hw_cpu:threads_policy\u003davoid|separate|prefer"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"If the policy is set to \u0027shared\u0027 no change will be made compared to the current"},{"line_number":41,"context_line":"default guest CPU placement policy. The guest vCPUs will be allowed to freely"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_15cb22a6","line":38,"in_reply_to":"7adec928_2030a29d","updated":"2014-05-28 12:58:58.000000000","message":"From the perspective of NFV workloads, cache efficiency is certainly a big part of the reason, but there are others too, such as the choice of PCIe devices, interrupt affinity configurations, etc.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"ee14b207ab64aae9e0dbf197e12ebed8e52c36a4","unresolved":false,"context_lines":[{"line_number":35,"context_line":"The flavour extra specs will be enhanced to support two new parameters"},{"line_number":36,"context_line":""},{"line_number":37,"context_line":"* hw_cpu:policy\u003dshared|dedicated"},{"line_number":38,"context_line":"* hw_cpu:threads_policy\u003davoid|separate|prefer"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"If the policy is set to \u0027shared\u0027 no change will be made compared to the current"},{"line_number":41,"context_line":"default guest CPU placement policy. The guest vCPUs will be allowed to freely"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_2030a29d","line":38,"in_reply_to":"7adec928_dd2a8b8f","updated":"2014-05-23 10:30:35.000000000","message":"NB compute capacity isn\u0027t actually the primary drive for dedicated pinning of vCPUs, rather than this is mostly about cache efficiency. To ensure predictable memory access latency for sensitive workloads in the guest, you want the guest to have dedicated CPUs where it always runs and no other guest can get scheduled trashing its L2/L3 caches.\n\nIf you\u0027re more interested in fairly allocating compute capacity is discrete chunks then floating CPUs in combination with schedular quotas is probably a better fit, since that does let you provide fine grained timeslices at a granularity smaller than 1 pCPU.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":1501,"name":"Phil Day","email":"philip.day@hp.com","username":"philip-day"},"change_message_id":"d1aa7de277de79e5de9fb257e8161dff4e1431bc","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"* hw_cpu:policy\u003dshared|dedicated"},{"line_number":38,"context_line":"* hw_cpu:threads_policy\u003davoid|separate|prefer"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"If the policy is set to \u0027shared\u0027 no change will be made compared to the current"},{"line_number":41,"context_line":"default guest CPU placement policy. The guest vCPUs will be allowed to freely"},{"line_number":42,"context_line":"float across host pCPUs, albeit potentially constrained by NUMA policy. If the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_7d0c1743","line":39,"updated":"2014-05-23 10:23:35.000000000","message":"I wonder if this isn\u0027t going to make the number of flavors explode - to cover every combination would need 6X the number of  flavors that are currently exposed.  I\u0027m not sure what a better answer would look like (at least a long flavor list makes it explicit what combinations are and aren\u0027t supported) - but I would like to at least open up the debate to see if we can\u0027t think of something more user friendly)","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"ee14b207ab64aae9e0dbf197e12ebed8e52c36a4","unresolved":false,"context_lines":[{"line_number":36,"context_line":""},{"line_number":37,"context_line":"* hw_cpu:policy\u003dshared|dedicated"},{"line_number":38,"context_line":"* hw_cpu:threads_policy\u003davoid|separate|prefer"},{"line_number":39,"context_line":""},{"line_number":40,"context_line":"If the policy is set to \u0027shared\u0027 no change will be made compared to the current"},{"line_number":41,"context_line":"default guest CPU placement policy. The guest vCPUs will be allowed to freely"},{"line_number":42,"context_line":"float across host pCPUs, albeit potentially constrained by NUMA policy. If the"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_80ced681","line":39,"in_reply_to":"7adec928_7d0c1743","updated":"2014-05-23 10:30:35.000000000","message":"If you tried to create a flavour for every possible  combination of settings, then yes it would get to be a large list, but I\u0027m not sure people will actually try to do that in reality. I think they\u0027d naturally trim out certain combinations that just don\u0027t make a whole lot of sense, so you might get a significant linear increase in flavour count, but not necessarily a combinatorial increase.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"697a82aa4e5bf97ac101c142bf178a3ef976cc1a","unresolved":false,"context_lines":[{"line_number":42,"context_line":"float across host pCPUs, albeit potentially constrained by NUMA policy. If the"},{"line_number":43,"context_line":"policy is set to \u0027dedicated\u0027 then the guest vCPUs will be strictly pinned to a"},{"line_number":44,"context_line":"set of host pCPUs. If the host CPU cores have multiple threads, then the guest"},{"line_number":45,"context_line":"CPU topology will be setup to expose the concept of threads."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"If the threads policy is set to \u0027avoid\u0027, the scheduler will avoid placing the"},{"line_number":48,"context_line":"guest on a host which has hyperthreads. If the threads policy is set to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_73e9bf19","line":45,"updated":"2014-05-22 16:56:16.000000000","message":"This last sentence... is that different to how libvirt currently does things?","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"4f1da15fb509591095454f0f1b6c140a14041e5a","unresolved":false,"context_lines":[{"line_number":42,"context_line":"float across host pCPUs, albeit potentially constrained by NUMA policy. If the"},{"line_number":43,"context_line":"policy is set to \u0027dedicated\u0027 then the guest vCPUs will be strictly pinned to a"},{"line_number":44,"context_line":"set of host pCPUs. If the host CPU cores have multiple threads, then the guest"},{"line_number":45,"context_line":"CPU topology will be setup to expose the concept of threads."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"If the threads policy is set to \u0027avoid\u0027, the scheduler will avoid placing the"},{"line_number":48,"context_line":"guest on a host which has hyperthreads. If the threads policy is set to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_0ce77813","line":45,"in_reply_to":"7adec928_13079b1e","updated":"2014-05-22 18:14:28.000000000","message":"Gotcha, thx for the explanation.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"61fdfa4e168c57e078f9d60b23f9b0b9b4f34798","unresolved":false,"context_lines":[{"line_number":42,"context_line":"float across host pCPUs, albeit potentially constrained by NUMA policy. If the"},{"line_number":43,"context_line":"policy is set to \u0027dedicated\u0027 then the guest vCPUs will be strictly pinned to a"},{"line_number":44,"context_line":"set of host pCPUs. If the host CPU cores have multiple threads, then the guest"},{"line_number":45,"context_line":"CPU topology will be setup to expose the concept of threads."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"If the threads policy is set to \u0027avoid\u0027, the scheduler will avoid placing the"},{"line_number":48,"context_line":"guest on a host which has hyperthreads. If the threads policy is set to"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_13079b1e","line":45,"in_reply_to":"7adec928_73e9bf19","updated":"2014-05-22 17:08:24.000000000","message":"By default all guests currently get topology of sockets\u003dnVCPUs,cores\u003d1,threads\u003d1. There is no attempt to copy the host topology into the guest topology, since that doesn\u0027t do anything useful, and is in fact harmful, unless you have strictly+exclusively pinned vCPUs\u003c-\u003epCPUs.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":6932,"name":"Adrian Hoban","email":"adrian.hoban@intel.com","username":"adrian-hoban"},"change_message_id":"671a8d67b63f8c2544201c877d0d4168f4317077","unresolved":false,"context_lines":[{"line_number":45,"context_line":"CPU topology will be setup to expose the concept of threads."},{"line_number":46,"context_line":""},{"line_number":47,"context_line":"If the threads policy is set to \u0027avoid\u0027, the scheduler will avoid placing the"},{"line_number":48,"context_line":"guest on a host which has hyperthreads. If the threads policy is set to"},{"line_number":49,"context_line":"\u0027separate\u0027 or \u0027prefer\u0027, the scheduler will place the guest on a host which"},{"line_number":50,"context_line":"does have threads. In case of \u0027separate\u0027 the guest will only be pinned to 1"},{"line_number":51,"context_line":"thread sibling per host core, while in the case of \u0027prefer\u0027 the guest will be"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_955572c8","line":48,"updated":"2014-05-28 12:58:58.000000000","message":"\"Avoid\" is a little ambiguous. I would prefer if this was more definitive, e.g. avoid would mean that the scheduler \"will not\" place the guest on a hyper-threaded CPU.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":9349,"name":"Jon Grimm","email":"jon.grimm@gmail.com","username":"jgrimm"},"change_message_id":"39b3b014468d0d22e281b7a91a091d4d2b6d66b4","unresolved":false,"context_lines":[{"line_number":49,"context_line":"\u0027separate\u0027 or \u0027prefer\u0027, the scheduler will place the guest on a host which"},{"line_number":50,"context_line":"does have threads. In case of \u0027separate\u0027 the guest will only be pinned to 1"},{"line_number":51,"context_line":"thread sibling per host core, while in the case of \u0027prefer\u0027 the guest will be"},{"line_number":52,"context_line":"pinned to all thread siblings of the host core."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The image metadata properties will also allow specification of the"},{"line_number":55,"context_line":"threads policy"}],"source_content_type":"text/x-rst","patch_set":2,"id":"1ae5cdf2_1cb8a8e4","line":52,"updated":"2014-06-16 21:03:48.000000000","message":"I\u0027m not quite clear what is being said.  Perhaps a couple examples are in order?     Assuming I have a 8 physical cores (each capable of 8 threads) and  I specify an 8 vCPU (1 socket 2 core 4 threads each) guest\u0027.   \n\n\u0027prefer\u0027 would pin all 8 vCPUs to a single physical core? or 4 vCPUs across 2 physical cores? \n\n\u0027separate\u0027 would pin all 8 vCPUs to different physical cores? Or? \n\nAnd then what if the guest topology were 4 vCPU (4 socket, 1 core, 1 thread)?  Same curiosity to the expected pinning behavior for separate and prefer. \n\nThanks for any help on understand better.  I\u0027m trying to think about this with respect to our new power8 systems:  1 and 2 socket models, where each socket supports 12 cores with each core capable of 8 threads, so this bp, along with guest cpu topology, numa placement, and huge table support are all quite useful knobs for fully taking advantage of the hardware platform.  Very good stuff.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":6932,"name":"Adrian Hoban","email":"adrian.hoban@intel.com","username":"adrian-hoban"},"change_message_id":"671a8d67b63f8c2544201c877d0d4168f4317077","unresolved":false,"context_lines":[{"line_number":49,"context_line":"\u0027separate\u0027 or \u0027prefer\u0027, the scheduler will place the guest on a host which"},{"line_number":50,"context_line":"does have threads. In case of \u0027separate\u0027 the guest will only be pinned to 1"},{"line_number":51,"context_line":"thread sibling per host core, while in the case of \u0027prefer\u0027 the guest will be"},{"line_number":52,"context_line":"pinned to all thread siblings of the host core."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The image metadata properties will also allow specification of the"},{"line_number":55,"context_line":"threads policy"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_d5053ac3","line":52,"updated":"2014-05-28 12:58:58.000000000","message":"I\u0027m not sure that the distinction between or definition of separate and prefer will be good enough for NFV use cases. \n\nE.g. If you use separate, then will it be possible that another guest can be launched that would end up consuming the other sibling on the host core? If so, this is not going to provide sufficient control.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":6932,"name":"Adrian Hoban","email":"adrian.hoban@intel.com","username":"adrian-hoban"},"change_message_id":"671a8d67b63f8c2544201c877d0d4168f4317077","unresolved":false,"context_lines":[{"line_number":50,"context_line":"does have threads. In case of \u0027separate\u0027 the guest will only be pinned to 1"},{"line_number":51,"context_line":"thread sibling per host core, while in the case of \u0027prefer\u0027 the guest will be"},{"line_number":52,"context_line":"pinned to all thread siblings of the host core."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":"The image metadata properties will also allow specification of the"},{"line_number":55,"context_line":"threads policy"},{"line_number":56,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_88d8e6f0","line":53,"updated":"2014-05-28 12:58:58.000000000","message":"There is no mechanism to specify the host cores that are required. I think this will need to be addressed for NFV use cases.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":6932,"name":"Adrian Hoban","email":"adrian.hoban@intel.com","username":"adrian-hoban"},"change_message_id":"671a8d67b63f8c2544201c877d0d4168f4317077","unresolved":false,"context_lines":[{"line_number":58,"context_line":""},{"line_number":59,"context_line":"This will only be honoured if the flavour does not already have a threads"},{"line_number":60,"context_line":"policy set. This ensures the cloud administrator can have absolute control"},{"line_number":61,"context_line":"over threads policy if desired."},{"line_number":62,"context_line":""},{"line_number":63,"context_line":"The schedular will have to be enhanced so that it considers the usage of CPUs"},{"line_number":64,"context_line":"by existing guests. Use of a dedicated CPU policy will have to be accompanied"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_d5ba9ae0","line":61,"updated":"2014-05-28 12:58:58.000000000","message":"Please see this alternative proposal (https://blueprints.launchpad.net/glance/+spec/epa-ovf-meta-data-import) for providing admin control on image requests.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":1501,"name":"Phil Day","email":"philip.day@hp.com","username":"philip-day"},"change_message_id":"d1aa7de277de79e5de9fb257e8161dff4e1431bc","unresolved":false,"context_lines":[{"line_number":62,"context_line":""},{"line_number":63,"context_line":"The schedular will have to be enhanced so that it considers the usage of CPUs"},{"line_number":64,"context_line":"by existing guests. Use of a dedicated CPU policy will have to be accompanied"},{"line_number":65,"context_line":"by the setup of aggregates to split the hosts into two groups, one allowing"},{"line_number":66,"context_line":"overcommit of shared pCPUs and the other only allowing dedicated CPU guests."},{"line_number":67,"context_line":"ie we do not want a situation with dedicated CPU and shared CPU guests on the"},{"line_number":68,"context_line":"same host. It is likely that the administrator will already need to setup host"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_40f4cef1","line":65,"updated":"2014-05-23 10:23:35.000000000","message":"I\u0027m not wild on having to pre-divide the available hosts into pools that do and don\u0027s have HT enabled, or do and don\u0027t support specific vCPU \u003c\u003e pCPU mappings.  It makes it really hard to make effective use of the available servers when you don\u0027t know in advance what users will request.\n\nIsn;t it possible for this to be more dynamic - ie. what addtional VMs a server can support depends on the cpu policy of the first instance scheduler there ?\n\nIt woudl presumably also be possible in theory to have a mix of dedicated and shared CPU VMs on the same host with some careful mapping of which ones use which groups of pCPUs - and I\u0027d rather see some though about how to expose that level of sophisticated placement exposed to the scheduler that  rather that the failry blunt pre-palce them in aggregates approach","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":1501,"name":"Phil Day","email":"philip.day@hp.com","username":"philip-day"},"change_message_id":"f4ee562fc50f32f1370e04e706d1965dfbba9e51","unresolved":false,"context_lines":[{"line_number":62,"context_line":""},{"line_number":63,"context_line":"The schedular will have to be enhanced so that it considers the usage of CPUs"},{"line_number":64,"context_line":"by existing guests. Use of a dedicated CPU policy will have to be accompanied"},{"line_number":65,"context_line":"by the setup of aggregates to split the hosts into two groups, one allowing"},{"line_number":66,"context_line":"overcommit of shared pCPUs and the other only allowing dedicated CPU guests."},{"line_number":67,"context_line":"ie we do not want a situation with dedicated CPU and shared CPU guests on the"},{"line_number":68,"context_line":"same host. It is likely that the administrator will already need to setup host"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_02948735","line":65,"in_reply_to":"7adec928_40f4cef1","updated":"2014-05-29 13:53:00.000000000","message":"If you are going to keep this limited to aggregates, would like to see details here of how the aggregate metadata will be matched to extra_specs, and if this is going to be a specific new filter for CPU pinning, or if you intend to produce a filter that can somehow be shared between large pages and CPU pinning","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"697a82aa4e5bf97ac101c142bf178a3ef976cc1a","unresolved":false,"context_lines":[{"line_number":65,"context_line":"by the setup of aggregates to split the hosts into two groups, one allowing"},{"line_number":66,"context_line":"overcommit of shared pCPUs and the other only allowing dedicated CPU guests."},{"line_number":67,"context_line":"ie we do not want a situation with dedicated CPU and shared CPU guests on the"},{"line_number":68,"context_line":"same host. It is likely that the administrator will already need to setup host"},{"line_number":69,"context_line":"aggregates for the purpose of using huge pages for guest RAM. The same grouping"},{"line_number":70,"context_line":"will be usable for both dedicated RAM (via huge pages) and dedicated CPUs (via"},{"line_number":71,"context_line":"pinning)."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_13c5db3c","line":68,"updated":"2014-05-22 16:56:16.000000000","message":"Just curious about something here.... why would we not want that? If a guest has pinned CPU resources, do guests without pinned CPU resources affect the performance of the pinned CPU guest? I was under the impression that \"floaters\" would be scheduled on non-pinned CPU resources only... is that not the case?","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"61fdfa4e168c57e078f9d60b23f9b0b9b4f34798","unresolved":false,"context_lines":[{"line_number":65,"context_line":"by the setup of aggregates to split the hosts into two groups, one allowing"},{"line_number":66,"context_line":"overcommit of shared pCPUs and the other only allowing dedicated CPU guests."},{"line_number":67,"context_line":"ie we do not want a situation with dedicated CPU and shared CPU guests on the"},{"line_number":68,"context_line":"same host. It is likely that the administrator will already need to setup host"},{"line_number":69,"context_line":"aggregates for the purpose of using huge pages for guest RAM. The same grouping"},{"line_number":70,"context_line":"will be usable for both dedicated RAM (via huge pages) and dedicated CPUs (via"},{"line_number":71,"context_line":"pinning)."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_d65a8129","line":68,"in_reply_to":"7adec928_13c5db3c","updated":"2014-05-22 17:08:24.000000000","message":"Floaters will float anywhere the there is available CPU time. So a if a pCPU associated with a pinned guest vCPU is not currently used by that guest, the kernel may schedule another guest\u0027s vCPU on that pCPU. This will trash the cache on that CPU, which is bad for the guest that was pinned to that CPU.\nMaintaining cache efficiency is the primary reason why users want to be able to pin vCPUs to pCPUs, instead of just letting them float. Hence we must not mix guests with floating vCPUs and guests with dedicated vCPUs on the same host.\nBasically all should be pinned or all should float, and not any mix in between.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"4f1da15fb509591095454f0f1b6c140a14041e5a","unresolved":false,"context_lines":[{"line_number":65,"context_line":"by the setup of aggregates to split the hosts into two groups, one allowing"},{"line_number":66,"context_line":"overcommit of shared pCPUs and the other only allowing dedicated CPU guests."},{"line_number":67,"context_line":"ie we do not want a situation with dedicated CPU and shared CPU guests on the"},{"line_number":68,"context_line":"same host. It is likely that the administrator will already need to setup host"},{"line_number":69,"context_line":"aggregates for the purpose of using huge pages for guest RAM. The same grouping"},{"line_number":70,"context_line":"will be usable for both dedicated RAM (via huge pages) and dedicated CPUs (via"},{"line_number":71,"context_line":"pinning)."}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_6cec7cf4","line":68,"in_reply_to":"7adec928_d65a8129","updated":"2014-05-22 18:14:28.000000000","message":"Got it.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":6772,"name":"Stephen Gordon","email":"sgordon@redhat.com","username":"sgordon"},"change_message_id":"0e47730895ea4c580cac4ba647c6c6c1022fc9d1","unresolved":false,"context_lines":[{"line_number":68,"context_line":"same host. It is likely that the administrator will already need to setup host"},{"line_number":69,"context_line":"aggregates for the purpose of using huge pages for guest RAM. The same grouping"},{"line_number":70,"context_line":"will be usable for both dedicated RAM (via huge pages) and dedicated CPUs (via"},{"line_number":71,"context_line":"pinning)."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Alternatives"},{"line_number":74,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_6b472d1e","line":71,"updated":"2014-05-21 15:40:14.000000000","message":"How will this split be reflected, and how does it mesh with the feature added in https://review.openstack.org/#/c/26363 whereby the administrator can \"reserve\" cores so that they aren\u0027t used by VMs (most typically so that they can pin other host-side processes such as the switching agent)?\n\nTo avoid confusion I think behaviour in relation to this needs to be explicitly stated.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"853ba86d08c4551a99a8e0857140924d59023c4d","unresolved":false,"context_lines":[{"line_number":68,"context_line":"same host. It is likely that the administrator will already need to setup host"},{"line_number":69,"context_line":"aggregates for the purpose of using huge pages for guest RAM. The same grouping"},{"line_number":70,"context_line":"will be usable for both dedicated RAM (via huge pages) and dedicated CPUs (via"},{"line_number":71,"context_line":"pinning)."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Alternatives"},{"line_number":74,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_cbd20134","line":71,"in_reply_to":"7adec928_6b472d1e","updated":"2014-05-21 15:42:38.000000000","message":"The notion of reserved host cores shouldn\u0027t really impact this - libvirt would continue to avoid placing guests on those reserved cores - we\u0027d basically treat them as if they are not available when considering availability to place guests.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":6772,"name":"Stephen Gordon","email":"sgordon@redhat.com","username":"sgordon"},"change_message_id":"1f3d2537b8d098daf8e9b0b88dd58a69fcb3d8c0","unresolved":false,"context_lines":[{"line_number":68,"context_line":"same host. It is likely that the administrator will already need to setup host"},{"line_number":69,"context_line":"aggregates for the purpose of using huge pages for guest RAM. The same grouping"},{"line_number":70,"context_line":"will be usable for both dedicated RAM (via huge pages) and dedicated CPUs (via"},{"line_number":71,"context_line":"pinning)."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"Alternatives"},{"line_number":74,"context_line":"------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"7adec928_abe1359c","line":71,"in_reply_to":"7adec928_cbd20134","updated":"2014-05-21 15:50:58.000000000","message":"OK, cool. There was another proposal in the queue that suggested that those reserved cores would be the ones used for dedicated resourcing (which I disagreed with), hence the desire to confirm.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":1501,"name":"Phil Day","email":"philip.day@hp.com","username":"philip-day"},"change_message_id":"f4ee562fc50f32f1370e04e706d1965dfbba9e51","unresolved":false,"context_lines":[{"line_number":126,"context_line":"dedicated CPU resources. The administrator will have to place hosts into groups"},{"line_number":127,"context_line":"using aggregates such that the schedular can separate placement of guests with"},{"line_number":128,"context_line":"dedicated vs shared CPUs. These aggregates will already be setup for huge large"},{"line_number":129,"context_line":"usage."},{"line_number":130,"context_line":""},{"line_number":131,"context_line":"Developer impact"},{"line_number":132,"context_line":"----------------"}],"source_content_type":"text/x-rst","patch_set":2,"id":"3ae8d1ca_a2c9137a","line":129,"updated":"2014-05-29 13:53:00.000000000","message":"Why the linkage with aggregates for large pages ?  Aren\u0027t they independent.","commit_id":"ca64aa0b1d293e7297e3c85ba27e9d7d8257752c"},{"author":{"_account_id":1501,"name":"Phil Day","email":"philip.day@hp.com","username":"philip-day"},"change_message_id":"6d0f831183dc0bd93a87151bb29de46e7780401f","unresolved":false,"context_lines":[{"line_number":49,"context_line":"of 1 socket, 1 core, 2 threads."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"The threads policy will control how the scheduler / virt driver place guests"},{"line_number":52,"context_line":"wrt CPU threads."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":" - avoid: the scheduler will not place the guest on a host which has"},{"line_number":55,"context_line":"   hyperthreads."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_4bc3b356","line":52,"updated":"2014-07-04 16:04:49.000000000","message":"Does the threads policy only take effect if the cpu_policy is \"dedicated\" ?\n\nIf so then I think that needs to be called out explicitly.\n\nIf not that seems to contradict that a cpu_policy of shared matches the current behaviour (as it would depend on the threads_policy.","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"4b50da2a32167e6d6d8e8de064591e379780b788","unresolved":false,"context_lines":[{"line_number":49,"context_line":"of 1 socket, 1 core, 2 threads."},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"The threads policy will control how the scheduler / virt driver place guests"},{"line_number":52,"context_line":"wrt CPU threads."},{"line_number":53,"context_line":""},{"line_number":54,"context_line":" - avoid: the scheduler will not place the guest on a host which has"},{"line_number":55,"context_line":"   hyperthreads."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_ab58cf8a","line":52,"in_reply_to":"baada198_4bc3b356","updated":"2014-07-04 16:12:17.000000000","message":"Correct, the threads policy only applies when cpu policy is dedicatd.","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":8276,"name":"kiwik","email":"chenrui.momo@gmail.com","username":"kiwik"},"change_message_id":"bf7fbfc403c0d052b516689b3c8b227ebd2c209f","unresolved":false,"context_lines":[{"line_number":60,"context_line":"   placed on the same core. ie one thread sibling is guaranteed to"},{"line_number":61,"context_line":"   always be unused,"},{"line_number":62,"context_line":" - prefer: if the host has threads, vCPU will be placed on the same"},{"line_number":63,"context_line":"   core, so they are thread siblings."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"The image metadata properties will also allow specification of the"},{"line_number":66,"context_line":"threads policy"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_822f9e87","line":63,"updated":"2014-07-03 12:56:23.000000000","message":"If the host have 1 socket 1 core 4 threads, instanceA with 2 vCPU used 2 threads, can the scheduler place instanceB with 2 vCPU into the same host to use other 2 threads in the same core when hw:cpu_threads_policy\u003dprefer?","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":9847,"name":"ricky.bo","email":"boh.ricky@gmail.com","username":"boh.ricky"},"change_message_id":"26262cc7733bd2ffc0b46b80451d9a48b929fd19","unresolved":false,"context_lines":[{"line_number":60,"context_line":"   placed on the same core. ie one thread sibling is guaranteed to"},{"line_number":61,"context_line":"   always be unused,"},{"line_number":62,"context_line":" - prefer: if the host has threads, vCPU will be placed on the same"},{"line_number":63,"context_line":"   core, so they are thread siblings."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"The image metadata properties will also allow specification of the"},{"line_number":66,"context_line":"threads policy"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_7c610604","line":63,"updated":"2014-07-07 08:03:01.000000000","message":"Whether the \"separate\"/\"isolate\"/\"prefer\" policy\u0027s instance has the possibility to be scheduled to the same host?\nAnd what will happen?","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"4039e8f91b1b232b30b04aab798e1d2b8db605b9","unresolved":false,"context_lines":[{"line_number":60,"context_line":"   placed on the same core. ie one thread sibling is guaranteed to"},{"line_number":61,"context_line":"   always be unused,"},{"line_number":62,"context_line":" - prefer: if the host has threads, vCPU will be placed on the same"},{"line_number":63,"context_line":"   core, so they are thread siblings."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"The image metadata properties will also allow specification of the"},{"line_number":66,"context_line":"threads policy"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_254df93e","line":63,"in_reply_to":"baada198_822f9e87","updated":"2014-07-03 14:26:22.000000000","message":"Yes, if you want other guests to avoid the left-over  2 threads, then this is what the \u0027isolate\u0027 policy is for.","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":8276,"name":"kiwik","email":"chenrui.momo@gmail.com","username":"kiwik"},"change_message_id":"bf7fbfc403c0d052b516689b3c8b227ebd2c209f","unresolved":false,"context_lines":[{"line_number":61,"context_line":"   always be unused,"},{"line_number":62,"context_line":" - prefer: if the host has threads, vCPU will be placed on the same"},{"line_number":63,"context_line":"   core, so they are thread siblings."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"The image metadata properties will also allow specification of the"},{"line_number":66,"context_line":"threads policy"},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_02138e0d","line":64,"updated":"2014-07-03 12:56:23.000000000","message":"If no host has enough threads to place all vCPU of instance into one core, is the schedule failure?","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"4039e8f91b1b232b30b04aab798e1d2b8db605b9","unresolved":false,"context_lines":[{"line_number":61,"context_line":"   always be unused,"},{"line_number":62,"context_line":" - prefer: if the host has threads, vCPU will be placed on the same"},{"line_number":63,"context_line":"   core, so they are thread siblings."},{"line_number":64,"context_line":""},{"line_number":65,"context_line":"The image metadata properties will also allow specification of the"},{"line_number":66,"context_line":"threads policy"},{"line_number":67,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_85fec5ac","line":64,"in_reply_to":"baada198_02138e0d","updated":"2014-07-03 14:26:22.000000000","message":"No, \u0027prefer\u0027 is a soft policy not a hard policy. It would look for hosts with cores or sockets instead.  If we need a hard policy that could be done with a nother \u0027require\u0027 policy","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":1501,"name":"Phil Day","email":"philip.day@hp.com","username":"philip-day"},"change_message_id":"6d0f831183dc0bd93a87151bb29de46e7780401f","unresolved":false,"context_lines":[{"line_number":66,"context_line":"threads policy"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* hw_cpu_threads_policy\u003davoid|separate|isolate|prefer"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"This will only be honoured if the flavour does not already have a threads"},{"line_number":71,"context_line":"policy set. This ensures the cloud administrator can have absolute control"},{"line_number":72,"context_line":"over threads policy if desired."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_8b96ab3d","line":69,"updated":"2014-07-04 16:04:49.000000000","message":"Is there a reason for not allowing the image to also specify the cpu_policy ?\n\nAssuming thread_policy depends on cpu_policy\u003ddedicated, it seems that this image property might be ignored even if the flavor has no threads policy if the cpu policy\u003dshared","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":1779,"name":"Daniel Berrange","email":"berrange@redhat.com","username":"berrange"},"change_message_id":"4b50da2a32167e6d6d8e8de064591e379780b788","unresolved":false,"context_lines":[{"line_number":66,"context_line":"threads policy"},{"line_number":67,"context_line":""},{"line_number":68,"context_line":"* hw_cpu_threads_policy\u003davoid|separate|isolate|prefer"},{"line_number":69,"context_line":""},{"line_number":70,"context_line":"This will only be honoured if the flavour does not already have a threads"},{"line_number":71,"context_line":"policy set. This ensures the cloud administrator can have absolute control"},{"line_number":72,"context_line":"over threads policy if desired."}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_6b62373f","line":69,"in_reply_to":"baada198_8b96ab3d","updated":"2014-07-04 16:12:17.000000000","message":"Access to dedicated resource flavours removes the ability to do overcommit on the host. As such any use of dedicated resource should be enabled at the flavour level to allow appropriate (higher) billing to be applied to accounts.  So allowing it to be requested on the image would allow users to bypassing billing which would be bad.","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":1561,"name":"Russell Bryant","email":"rbryant@redhat.com","username":"russellb"},"change_message_id":"fa0e9831fe2eae4807466161a02682fe35becb66","unresolved":false,"context_lines":[{"line_number":83,"context_line":""},{"line_number":84,"context_line":"The compute host already has a notion of CPU sockets which are reserved for"},{"line_number":85,"context_line":"execution of base operating system services. This facility will be preserved"},{"line_number":86,"context_line":"unchanged. ie dedicatd CPU guests will only be placed on CPUs which are not"},{"line_number":87,"context_line":"marked as reserved for the base OS."},{"line_number":88,"context_line":""},{"line_number":89,"context_line":"Alternatives"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_85385af0","line":86,"updated":"2014-07-04 15:24:13.000000000","message":"typo on dedicated","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":1501,"name":"Phil Day","email":"philip.day@hp.com","username":"philip-day"},"change_message_id":"6d0f831183dc0bd93a87151bb29de46e7780401f","unresolved":false,"context_lines":[{"line_number":93,"context_line":"latency free of cache effects from other guests working on the host, that does"},{"line_number":94,"context_line":"not involve CPU pinning."},{"line_number":95,"context_line":""},{"line_number":96,"context_line":"Above the suggestion is to use host aggregates for grouping compute hosts into"},{"line_number":97,"context_line":"those for dedicated vs overcommit CPU policy. An alternative would be to allow"},{"line_number":98,"context_line":"compute hosts to have both dedicated and overcommit guests, splitting them onto"},{"line_number":99,"context_line":"separate sockets. ie if there were for sockets, two sockets could be used for"}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_2babdf75","line":96,"updated":"2014-07-04 16:04:49.000000000","message":"\"The proposed solution\" or \"The solution above\" would read better","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"},{"author":{"_account_id":4393,"name":"Dan Smith","email":"dms@danplanet.com","username":"danms"},"change_message_id":"2e774859d852e8bc5307314b0b98a5363863b4c8","unresolved":false,"context_lines":[{"line_number":134,"context_line":"Notifications impact"},{"line_number":135,"context_line":"--------------------"},{"line_number":136,"context_line":""},{"line_number":137,"context_line":"No imapct."},{"line_number":138,"context_line":""},{"line_number":139,"context_line":"The notifications system is not used by this change."},{"line_number":140,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"baada198_0616e24b","line":137,"updated":"2014-07-07 17:28:43.000000000","message":"impact is misspelled.","commit_id":"d6bd2f2bb4dea10a428a12b059faaf2a3a364054"}]}