| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-11 | |||
| 13:19:54 | luyao | sean-k-mooney: yes | |
| 13:20:03 | sean-k-mooney | well qemu said it can | |
| 13:20:14 | sean-k-mooney | what error did you get | |
| 13:20:18 | stephenfin | But rendered HTML is better (for me, anyway) ;-) | |
| 13:20:36 | sean-k-mooney | stephenfin: and much worse for me :) | |
| 13:20:43 | stephenfin | Is dansmith around yet? | |
| 13:22:06 | luyao | sean-k-mooney: I don't remember it clearly, something like you must specify an numa node | |
| 13:22:25 | sean-k-mooney | can you test it again | |
| 13:22:31 | luyao | sean-k-mooney: actually, the libvirt part you mentioned is my updating before | |
| 13:22:39 | sean-k-mooney | ill try a nested env to test it | |
| 13:22:59 | sean-k-mooney | which libvirt part | |
| 13:23:11 | luyao | sean-k-mooney: About the nvdimm config | |
| 13:23:55 | sean-k-mooney | right the libvirt doc say the node is optional in the target | |
| 13:24:11 | sean-k-mooney | so libvirt hsould not require a numa toplogy | |
| 13:24:33 | sean-k-mooney | and the qemu examle does not create a numa toplogy | |
| 13:24:50 | openstackgerrit | Chris Dent proposed openstack/os-traits master: Build pdf docs https://review.opendev.org/681465 | |
| 13:25:46 | openstackgerrit | Chris Dent proposed openstack/os-resource-classes master: Build pdf docs https://review.opendev.org/681463 | |
| 13:26:06 | luyao | sean-k-mooney: that node description is for all memory devices, for nvdimm , we do need a numa | |
| 13:26:19 | luyao | sean-k-mooney: I'll try to do a test | |
| 13:27:06 | sean-k-mooney | i think we may only need the node to be set if there is a numa node in the guest | |
| 13:27:15 | sean-k-mooney | if its not present i think we wont need it | |
| 13:27:19 | openstackgerrit | Luyao Zhong proposed openstack/nova master: libvirt: report VPMEM resources by provider tree https://review.opendev.org/678454 | |
| 13:27:19 | openstackgerrit | Luyao Zhong proposed openstack/nova master: libvirt: Enable driver discovering PMEM namespaces https://review.opendev.org/678453 | |
| 13:27:20 | openstackgerrit | Luyao Zhong proposed openstack/nova master: Parse vpmem related flavor extra spec https://review.opendev.org/678456 | |
| 13:27:20 | openstackgerrit | Luyao Zhong proposed openstack/nova master: libvirt: Support VM creation with vpmems and vpmems cleanup https://review.opendev.org/678455 | |
| 13:27:21 | openstackgerrit | Luyao Zhong proposed openstack/nova master: Add functional tests for virtual persistent memory https://review.opendev.org/678470 | |
| 13:27:21 | openstackgerrit | Luyao Zhong proposed openstack/nova master: libvirt: Enable driver configuring PMEM namespaces https://review.opendev.org/679640 | |
| 13:27:22 | openstackgerrit | Luyao Zhong proposed openstack/nova master: objects: use all_things_equal from objects.base https://review.opendev.org/681397 | |
| 13:27:43 | sean-k-mooney | so we could hard code it ot 0 if there is a numa toplogy and not set it if there is not | |
| 13:30:01 | mriedem | why is it that Intel_Zuul comments can't be hidden with the 3rd party toggle CI button? | |
| 13:30:14 | sean-k-mooney | it does not have CI in the name | |
| 13:30:22 | mriedem | blarg | |
| 13:30:23 | sean-k-mooney | which it should have | |
| 13:30:26 | mriedem | alex_xu: ^ can we get that fixed? | |
| 13:32:37 | openstackgerrit | sean mooney proposed openstack/nova master: [DNM] pmem pull request test. https://review.opendev.org/681474 | |
| 13:33:07 | sean-k-mooney | efried: alex_xu luyao in theory ^ should cause the intel ci to run with my pull request that removes the hardcoding | |
| 13:33:52 | sean-k-mooney | it also might make the first party ci unhappy but i have turned off all the check test anyway | |
| 13:34:46 | mriedem | artom: you still have a busted test in https://review.opendev.org/#/c/634606/84 but if you want to tack on a follow up patch to the end of the series i wouldn't be opposed to just fixing it that way | |
| 13:35:06 | artom | mriedem, what's the risk in pushing a new PS? | |
| 13:35:23 | mriedem | is dan doing reviews on the other patches later up the stack? | |
| 13:35:38 | mriedem | just wait for me to hit https://review.opendev.org/#/c/640021/50 again quick | |
| 13:36:55 | artom | Ack | |
| 13:37:40 | openstackgerrit | sean mooney proposed openstack/nova master: [DNM] pmem pull request test. https://review.opendev.org/681474 | |
| 13:37:40 | efried | stephenfin, sean-k-mooney, luyao: here's spec discussion about numa stuff https://review.opendev.org/#/c/601596/16/specs/train/approved/virtual-persistent-memory.rst@270 | |
| 13:38:50 | efried | and the one below it | |
| 13:39:10 | sean-k-mooney | efried: yes they have implemented what the spec said but its still problemenatic | |
| 13:39:34 | efried | but you agreed it was okay to be consistent with the other problematic things that do the same? | |
| 13:39:44 | sean-k-mooney | it is not consitent4 | |
| 13:39:50 | stephenfin | yeah, it's not consistent | |
| 13:39:54 | stephenfin | that's the bit I don't like | |
| 13:39:59 | stephenfin | at all at all | |
| 13:40:00 | sean-k-mooney | the other thing actully pin the cores and memoyr to a host numa node | |
| 13:40:23 | efried | oh, so it's bad in a different way than the other things are bad | |
| 13:40:31 | efried | and we'd rather have it be consistently bad. | |
| 13:40:35 | sean-k-mooney | the other things imporve performance | |
| 13:40:51 | efried | but we're agreed it's too hard to have it be good (and inconsistent) until "later". | |
| 13:40:52 | sean-k-mooney | this does not and it make the other code more complex | |
| 13:41:26 | sean-k-mooney | efried: it hink we can get the same beahvior if we jsut dont set the node elemnt in the xml | |
| 13:41:34 | stephenfin | efried: I'm not sure what you mean | |
| 13:41:36 | sean-k-mooney | and dont create a numa toplogy at all | |
| 13:41:54 | stephenfin | we're saying it should either not have a NUMA topology, if that's possible (which sean-k-mooney thinks it is) | |
| 13:42:09 | stephenfin | and if it has a NUMA topology, it should behave like everything else with NUMA topologies | |
| 13:43:13 | stephenfin | namely, each guest NUMA node is mapped to a unique host NUMA node | |
| 13:43:49 | sean-k-mooney | im going to quickly update my multi numa test and start stacking the latest version of atroms code then manully try to test if a numa toplogy is need for pmem | |
| 13:43:50 | stephenfin | if we want to loosen that constraint in the future, grand, but it should be done across the board (so hugepages too) | |
| 13:44:21 | luyao | sean-k-mooney: http://paste.openstack.org/show/775121/ | |
| 13:44:33 | efried | - So do it the same bad as the "other resources" for now | |
| 13:44:33 | efried | - Doing it "good" is hard | |
| 13:44:33 | efried | - The way pmem is doing it in the current PS is bad, but different bad from ^ | |
| 13:44:33 | efried | - The way other resources "do it" is bad | |
| 13:44:33 | efried | I don't understand the issue, so I'm just operating at a very abstract level. My understanding: | |
| 13:44:34 | efried | - ...unless we can do it good now, easily. | |
| 13:44:34 | efried | - And some time in the future, make all the things do it good. | |
| 13:44:58 | sean-k-mooney | luyao: remove the numa element on line 7-9 | |
| 13:45:22 | sean-k-mooney | if you have numa element in the cpu element i think you need node to be se | |
| 13:45:26 | sean-k-mooney | *set | |
| 13:45:32 | sean-k-mooney | if you dont you should not | |
| 13:46:13 | sean-k-mooney | efried: by they i dont think doing it "good" was hard but let not dwell on that | |
| 13:46:16 | stephenfin | luyao: Yeah, you're hitting this https://github.com/libvirt/libvirt/blob/master/src/qemu/qemu_domain.c#L11525-L11532 | |
| 13:46:41 | sean-k-mooney | efried: also the way the other numa toplogy stuff works is not bad | |
| 13:46:54 | stephenfin | - The way other resources "do it" is bad | |
| 13:46:56 | stephenfin | it's not bad | |
| 13:47:02 | stephenfin | there's a very good reason we do that | |
| 13:47:02 | sean-k-mooney | i just wish it was less copled | |
| 13:47:25 | efried | okay, this reinforces that I should not be involved with this part of the series. | |
| 13:47:36 | stephenfin | not at all | |
| 13:47:48 | stephenfin | just that we have strong opinions about this stuff ;) | |
| 13:47:52 | sean-k-mooney | efried: this is why we do it https://software.intel.com/en-us/articles/openstack-epa-feature-breakdown-and-analysis#inpage-nav-6-3 | |
| 13:48:31 | efried | sean-k-mooney: ^ meaning that even if there's only one NUMA node, turning NUMA "on" is better perf than leaving it "off"? | |
| 13:48:43 | sean-k-mooney | the numa affintiy on old systems gave you like 7-10% performacne improvement on its own | |
| 13:49:27 | sean-k-mooney | efried: yes because if the host has multiple numa nodes the vm wont use remote memory form the other numa node or float across them | |
| 13:49:43 | sean-k-mooney | if the host has one numa nod its has no effect | |
| 13:50:03 | efried | yahbut... | |
| 13:50:19 | efried | what if my VM needs more CPUs than are available in one NUMA node? | |
| 13:50:41 | sean-k-mooney | create a vm with 2 numa nodes | |
| 13:50:49 | efried | no, I mean... | |
| 13:50:52 | sean-k-mooney | it will perfome better | |
| 13:51:15 | efried | IIUC we're doing this thing to create an implicit single-NUMA guest if no NUMA topo was specified? To realize this perf gain. | |
| 13:51:16 | sean-k-mooney | i get the argument that people dont care | |
| 13:51:20 | sean-k-mooney | and i want ot support that | |