| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-07-19 | |||
| 08:06:10 | kashyap | Right | |
| 08:06:29 | kashyap | We already today warn if any anyone specifies the "CMT" 'performance' events via Nova's config attributes | |
| 08:06:43 | cdent | kill it! kill it with fire! | |
| 08:06:51 | kashyap | Hehe, yeah. | |
| 08:07:31 | kashyap | However there are *other* 'perf' events besides the CMT variants. So I asked on the mailing list if anyone is using them at all. | |
| 08:07:54 | kashyap | [While bearing in mind -discuss list audience does not represent all users ever :D] | |
| 08:13:47 | alex_xu | kashyap: we can write other event than cmt https://github.com/openstack/nova/blob/master/nova/conf/libvirt.py#L785 | |
| 08:14:26 | kashyap | alex_xu: Right, I wrote that documentation :-) | |
| 08:14:48 | kashyap | I was merely wondering if there are real-world users who are using these other events at all | |
| 08:15:06 | alex_xu | kashyap: I missed understand that conf only can can fill cmt, mbm..etc | |
| 08:15:26 | kashyap | No, not really -- any of the allowable `perf` events by libvirt | |
| 08:15:35 | alex_xu | kashyap: yes, that is always a question hard to answer | |
| 08:15:35 | kashyap | Hence my question on the list about *non-CMT* events | |
| 08:15:44 | kashyap | Right | |
| 08:17:03 | alex_xu | oops | |
| 08:19:08 | kashyap | alex_xu: Sorry if I didn't phrase it clearly. | |
| 09:29:26 | openstackgerrit | zhangyangyang proposed openstack/nova master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/671694 | |
| 10:32:22 | openstackgerrit | zhangyangyang proposed openstack/nova master: Bump the openstackdocstheme extension to 1.20 https://review.opendev.org/671694 | |
| 11:35:10 | artom | alex_xu, still around? I figure we can talk here rather than on gerrit, about vpmem and NUMA LM | |
| 11:44:57 | artom | So the current flow is driver.cclm_dest -> rpc.cclm_source -> claim -> driver.numa_config | |
| 11:45:19 | artom | The claim has to happen before driver.numa_config, and presumably before driver.vpmem_config or whatever you'd call it | |
| 11:45:53 | artom | And rpc.cclm_source has to happen before the claim, because the source will tell the destination if it's trying to perform a NUMA live migration | |
| 11:46:14 | artom | (We can't just check instance.numa_topology because the source might be an old compute) | |
| 11:46:24 | artom | (But that could change in a later release) | |
| 11:46:57 | artom | So really the question is, can rpc.cclm_source happen before driver.cclm_dest | |
| 11:47:36 | artom | *what | |
| 11:48:04 | artom | Ah, it's passed the dest_check_data | |
| 11:51:12 | artom | So it doesn't look like we can change the order | |
| 11:51:33 | artom | I'll put all that ^^ in gerrit :) | |
| 13:22:43 | efried | stephenfin: there's this spec https://review.opendev.org/#/c/668656 about mixing VCPU/PCPU in one instance. | |
| 13:22:49 | efried | I see you looked at it a few patch sets ago | |
| 13:23:01 | stephenfin | Yup. I really don't want that to happen this cycle | |
| 13:23:12 | efried | oh | |
| 13:23:13 | efried | whyzat? | |
| 13:23:24 | stephenfin | I've been working on cpu-resources, which that relies on, all this week and a good bit of last week | |
| 13:23:40 | efried | yes, obviously that's a hard dep | |
| 13:23:46 | stephenfin | The upgrade scenario is tricky af | |
| 13:24:19 | stephenfin | but it's being made easier by some assumptions I can make through a VM being all one kind of CPU | |
| 13:24:31 | efried | you mean reshaping allocations? | |
| 13:24:39 | stephenfin | Among other things, yeah | |
| 13:24:43 | efried | Hm | |
| 13:25:01 | stephenfin | The reason we dragged that out in the first place was because cpu-resources was horribly complex | |
| 13:25:07 | efried | yeah, I get that. | |
| 13:25:16 | efried | can a VM today have pinned and shared? | |
| 13:25:24 | stephenfin | Not today, no | |
| 13:25:33 | efried | oh, I see. Yeah, that makes a difference. | |
| 13:25:38 | stephenfin | Except for emulator threads | |
| 13:25:45 | stephenfin | But that's not the same thing at all | |
| 13:26:01 | stephenfin | Anyway, I'm not sure why dragging that complexity back in would be something we'd ever want to do | |
| 13:26:09 | efried | well | |
| 13:26:18 | stephenfin | This cycle, that is | |
| 13:26:20 | efried | there's a strong customer use case | |
| 13:26:22 | stephenfin | Next cycle, I'm all over that | |
| 13:26:42 | efried | tbc, the ask on you would be review, not code | |
| 13:26:50 | stephenfin | I figured there might be, aye :) | |
| 13:27:38 | efried | just not sure why we would want to say "next cycle" rather than "once cpu-resources is done" | |
| 13:27:46 | stephenfin | Tell you what, let's wait til I have code up | |
| 13:27:50 | stephenfin | Ha, jinx | |
| 13:27:54 | efried | which may wind up being the same thing, but ... yeah | |
| 13:28:04 | efried | except that spec freeze is next week | |
| 13:28:12 | stephenfin | Yeah, I'd like to wait to see how cpu-resources goes before committing to anything | |
| 13:28:21 | stephenfin | I wanted to have that up this week but unit test coupling is killing me | |
| 13:28:27 | stephenfin | and I haven't even started on the reshape | |
| 13:28:37 | efried | as you well know, approving a spec for this release doesn't "commit" us to getting it in this release. | |
| 13:29:09 | stephenfin | Technically, no, but it does send the wrong message to people that aren't as involved in nova as we are | |
| 13:29:11 | stephenfin | (PMs) | |
| 13:29:22 | efried | It would be a better story for Alex et al if they could go back and tell their downstream "approved, but considerable risk due to deps" than "no chance in Train". | |
| 13:29:33 | efried | yeah, Alex and I can manage PM expectations :) | |
| 13:29:38 | stephenfin | Suggesting we think this can land when I, for example, have very little confidence that it will | |
| 13:29:47 | stephenfin | Oh, I'm worried about my PM :P | |
| 13:30:14 | efried | okay. Alex and I can't manage your PM. | |
| 13:30:24 | stephenfin | Not sure anyone can, heh | |
| 13:30:31 | stephenfin | Anyway, not really the point | |
| 13:31:22 | stephenfin | As above, I'm not confident about landing that feature, but if the ask is to just review the spec, I can do that | |
| 13:31:54 | stephenfin | Though not today. I want to keep chipping away at these unit tests and hopefully get the first few patches pushed | |
| 13:32:26 | efried | I think it would be a good step if we can get you & sean-k-mooney agreeing to the design itself, before spec freeze. | |
| 13:33:03 | stephenfin | Yeah, that makes sense | |
| 13:33:10 | efried | Then we can armwrestle over whether it makes sense to merge it for Train with the caveat of high risk, or merge it in backlog/ | |
| 13:33:33 | stephenfin | Okay, I can set aside time to do that early next week, maybe in person with sean-k-mooney | |
| 13:33:39 | efried | thank you sir | |
| 13:33:46 | efried | and with alex_xu | |
| 13:34:14 | sean-k-mooney | sorry was away form my laptop what was the context? | |
| 13:34:14 | stephenfin | In person might be tough there, but sure :) | |
| 13:34:23 | efried | easier for you than for me. | |
| 13:34:36 | sean-k-mooney | efried: i think he ment alex | |
| 13:34:46 | efried | sean-k-mooney: we're talking about the mixed PCPU/VCPU spec | |
| 13:34:57 | sean-k-mooney | oh ok | |
| 13:35:40 | efried | TLDR, stephenfin and I both agree it would be quite high risk for Train, and need to decide whether we want to merge it with that caveat or take a hard line and explicitly punt it. But in either case, I would like to see the design sorted before spec freeze, so we merge it either to train/ or backlog/. | |
| 13:35:52 | sean-k-mooney | for what its worth i think we could do that but im concerned with the scope. e.g. if we had completed teh rest fo the cpu stuff by m2 i would have been fine with it | |
| 13:36:30 | sean-k-mooney | efried: ok | |
| 13:36:35 | sean-k-mooney | ill look at it again | |
| 13:36:41 | efried | thanks | |
| 13:36:46 | sean-k-mooney | i think at most we only need 1 extraspec | |
| 13:37:18 | sean-k-mooney | not the two that are proposed. and i would prefer it to be a new one rather then messing with hw:cpu_policy | |
| 13:37:37 | sean-k-mooney | spec freeze is wednesday right? | |
| 13:37:49 | sean-k-mooney | or thrusday? next week in either case | |
| 13:38:01 | stephenfin | I'd rather we used 'resources:VCPU' and 'resources:PCPU' but I don't recall why that wasn't chosen again | |
| 13:38:04 | stephenfin | I need to look at it again | |
| 13:38:10 | stephenfin | next week though! | |
| 13:38:37 | sean-k-mooney | stephenfin: because we never want people ot use resocues: driectly and that does not provide a way to say which cpus are the pinned ones | |