| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-03-13 | |||
| 16:28:01 | kashyap | It's in context of https://review.opendev.org/#/c/709494/ | |
| 16:28:04 | sean-k-mooney | ya i was trying to and could not fiutre it out | |
| 16:28:29 | sean-k-mooney | so this has changed form the old advise of use the VIRT cpu model | |
| 16:28:42 | melwitt | kashyap: yeah so I think what should likely happen is that once they have the CI set up and running we will update the feature support matrix with all of the things that are working in the CI? | |
| 16:31:09 | kashyap | sean-k-mooney: No, no you're mixing up CPU model and machine type for AArch64 | |
| 16:31:20 | kashyap | sean-k-mooney: 'virt' is still the recommended machine type for AArch64. | |
| 16:31:32 | kashyap | melwitt: Yeap. | |
| 16:31:33 | sean-k-mooney | ah yes i am | |
| 16:31:45 | melwitt | cool | |
| 16:31:54 | sean-k-mooney | this still will cause issue for live migration if we use max | |
| 16:32:08 | sean-k-mooney | so i dont know if that is a good default | |
| 16:32:13 | kashyap | melwitt: I _think_ first want to care about TCG, because for KVM, you'd need AArch64 hardware in the CI | |
| 16:32:25 | kashyap | sean-k-mooney: I've talked to the AArch64 maintainer, I'm posting the recommendations in the patch. | |
| 16:32:31 | sean-k-mooney | kashyap: we have AArch64 hardware in ci | |
| 16:32:33 | melwitt | kashyap: ack | |
| 16:32:46 | sean-k-mooney | kashyap: thats the whole point lenario donated some | |
| 16:32:49 | kashyap | sean-k-mooney: Good, then. We've got the recommendations for that, too. | |
| 16:32:56 | melwitt | kashyap: so do you think TCG would be a separate column in the matrix? | |
| 16:32:58 | kashyap | Linaro, I take it. Yeah | |
| 16:33:05 | kashyap | melwitt: Yeah, I'd say so. | |
| 16:33:08 | sean-k-mooney | ah yes | |
| 16:33:14 | melwitt | ok. thanks for explaining all this | |
| 16:33:16 | kashyap | (We need to clearly distinguish both cases.) | |
| 16:33:25 | kashyap | No worries, I need to refresh this every few months mysel f:D | |
| 16:33:34 | melwitt | :) | |
| 16:33:53 | sean-k-mooney | kashyap: we proably should be using the cpu_mode config option to define this | |
| 16:34:30 | sean-k-mooney | e.g. tie it in to host-passthough and host-model some how | |
| 16:35:37 | stephenfin | sean-k-mooney: how strongly do you feel about https://review.opendev.org/#/c/468203 ? | |
| 16:35:45 | stephenfin | specifically jaypipes arguments there | |
| 16:35:47 | kashyap | sean-k-mooney: One thing at a time :-) | |
| 16:36:00 | sean-k-mooney | im also not sure how i feel about htis being a bug, it fells more like a specless blueprint but im not going to really object too stronly to it beign a bug | |
| 16:37:00 | stephenfin | I ask because I'm trying to decide how to say "these cores should be dedicated" in a mixed instance | |
| 16:37:16 | sean-k-mooney | kashyap: well for now they could jsut use cpu_mode=custom and cpu_model=max or cpu_model=min right | |
| 16:37:35 | stephenfin | Currently I'm going with 'hw:cpu_dedicated_mask', which is a CPU list | |
| 16:37:38 | sean-k-mooney | stephenfin: am ill take a look now | |
| 16:37:48 | sean-k-mooney | stephenfin: ya i would be fine with that | |
| 16:37:55 | sean-k-mooney | stephenfin: whats the other option | |
| 16:38:05 | stephenfin | there are a few | |
| 16:38:34 | stephenfin | in this scenario that I'm following, you'll be able to use hw:cpu_dedicated_mask *or* hw:cpu_realtime_mask | |
| 16:38:59 | sean-k-mooney | stephenfin: no you would use both | |
| 16:39:01 | stephenfin | I see no reason to say these cores are shared, these are dedicated but non-realtime, and these are dedicated and realtime | |
| 16:39:04 | sean-k-mooney | well optinally | |
| 16:39:16 | sean-k-mooney | e.g. not an exclucive or | |
| 16:39:41 | sean-k-mooney | i dont see a reason to block it | |
| 16:39:41 | stephenfin | why? What real-world user is going to use all three types of core in an instance? | |
| 16:39:49 | stephenfin | Because it's less complicated | |
| 16:39:55 | sean-k-mooney | its more complicated | |
| 16:40:20 | sean-k-mooney | the validation logic to prevent all 3 is extra logic we dont need if we allow it | |
| 16:40:45 | stephenfin | A|B is easier grok than A.issubset(B) | |
| 16:40:56 | stephenfin | and the it makes my XML generation easier | |
| 16:41:02 | stephenfin | s/the // | |
| 16:41:04 | sean-k-mooney | stephenfin: you are over loading hw:cpu_realtime_mask | |
| 16:41:18 | sean-k-mooney | its behavior would change based on the hw:cpu_policy | |
| 16:41:29 | sean-k-mooney | so that gets harder to reason about | |
| 16:41:36 | stephenfin | nope, it stays the same: these are cores that are real-time | |
| 16:41:39 | sean-k-mooney | if we allow both it does not | |
| 16:41:41 | stephenfin | what changes is what happens to the other cores | |
| 16:41:53 | stephenfin | and that's purely based on hw:cpu_policy | |
| 16:42:10 | sean-k-mooney | no it chacnge form tehse are realtime to these are realtime and dedicated and the rest flaot | |
| 16:42:17 | kashyap | sean-k-mooney: Not entirely; there's also a quirk of making sure to specify the interrupt controller (as the default is less featureful) -- `-machine gic-version=max` | |
| 16:42:29 | kashyap | melwitt: For later, added my notes in the change. | |
| 16:42:32 | stephenfin | they're always realtime and dedicated | |
| 16:42:39 | stephenfin | you can't have realtime floating cores | |
| 16:42:45 | melwitt | kashyap: thanks | |
| 16:43:05 | sean-k-mooney | well libvirt allows you to but that is a seperate thign | |
| 16:43:14 | stephenfin | ...in nova | |
| 16:43:14 | kashyap | Yep | |
| 16:43:20 | sean-k-mooney | stephenfin: my perference would be to allow both to be set | |
| 16:43:38 | stephenfin | I could allow it, but I don't want to force it | |
| 16:43:46 | sean-k-mooney | and always require hw:dedicated_cpu_mask for mixed | |
| 16:43:58 | stephenfin | and because I don't want to force it, I'd rather say there's only one way to do this | |
| 16:44:14 | sean-k-mooney | which one do you not want to force | |
| 16:44:32 | sean-k-mooney | the realtime mask or the dedicated mask | |
| 16:44:33 | stephenfin | having to set both hw:cpu_dedicated_mask and hw:cpu_realtime_mask | |
| 16:44:46 | sean-k-mooney | right so i would make the cpu_realtime_mask optional | |
| 16:44:50 | stephenfin | if you want a real-time instance with the non-realtime cores floating | |
| 16:44:55 | sean-k-mooney | and always require the cpu_dedicated_mask | |
| 16:45:18 | stephenfin | but then you have a difference of behavior elsewhere | |
| 16:45:28 | sean-k-mooney | and make it so that if you dont set cpu_realtime_mask but do set hw:cpu_realtime=true then we use the hw:dedciated_cpu_mask | |
| 16:45:41 | stephenfin | now you have to use 'hw:cpu_realtime_mask' when using dedicated | |
| 16:45:52 | stephenfin | but use 'hw:cpu_dedicated_mask' when using mixed | |
| 16:46:48 | stephenfin | anyway, we'll invariably debate this in the patch so back to my original question | |
| 16:46:52 | sean-k-mooney | i think its a much simpler rule to say if you want realtime always use realtime_mask and if you want mixed always use the dedicated_mask | |
| 16:47:18 | sean-k-mooney | if you want both use both and require the realtime mask must be a subset of the dedicated mask | |
| 16:47:32 | stephenfin | if we're doing this, do we want to fix that annoying thing where hw:cpu_realtime_mask has to be preceded by carat? | |
| 16:47:43 | stephenfin | because I don't want to force that 'hw:cpu_dedicated_mask' | |
| 16:47:54 | stephenfin | and it would be nice for them to behave similarly | |
| 16:48:05 | sean-k-mooney | stephenfin: ya i would not mind doing that | |
| 16:48:23 | sean-k-mooney | stephenfin: we said the dedicated mask should follow the rules for the config opntion | |
| 16:48:30 | sean-k-mooney | not the rules for the realtime mask | |
| 16:48:33 | stephenfin | the only reason I see to not do that is jaypipes wanted us to kill 'hw:cpu_realtime_mask' in favor of 'hw:cpu_realtime_set' | |
| 16:48:42 | stephenfin | but tbh, I don't think it's worth the effort | |
| 16:48:55 | stephenfin | we haven't deprecated flavor extra specs before. I don't even want to get into that | |
| 16:49:06 | sean-k-mooney | i would be ok with that i guess but yat that ^ | |
| 16:49:10 | stephenfin | ditto for image metadata props, for that matter | |
| 16:49:33 | stephenfin | okay, sweet | |
| 16:49:40 | stephenfin | I can revive those patches so | |
| 16:49:43 | stephenfin | whoo, rebase fun! | |
| 16:50:31 | sean-k-mooney | stephenfin: cool. i prefer each option to do one thing and one thing only. but do what you think is best | |
| 16:50:42 | sean-k-mooney | its a preference not a blocker for me | |