| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-12 | |||
| 13:43:19 | stephenfin | efried: Hmm, can we discuss that on the spec so I can write something longer. I'm clearly not doing a good job of explaining here | |
| 13:43:21 | efried | mriedem: But that guy is failing the same way http://logs.openstack.org/17/554317/3/check/nova-multiattach/fd35a93/logs/screen-n-cpu.txt.gz?level=ERROR | |
| 13:43:49 | stephenfin | and/or I'm missing what sahid is trying to say | |
| 13:44:01 | stephenfin | efried: bauzas can just choose one and we'll weigh in there | |
| 13:44:10 | efried | fair | |
| 13:47:19 | sahid | i just saying that our current behavior to handle numa topology for guests is right we should not consider ok a guest requesting 2 NUMA nodes fit on one host NUMA node | |
| 13:47:32 | mriedem | efried: i think this is the problem http://logs.openstack.org/17/554317/3/check/nova-multiattach/fd35a93/logs/devstacklog.txt.gz#_2018-04-11_18_10_24_388 | |
| 13:48:58 | sahid | that because it's all performance related and user are going to place thier applications based on guest topology. if we provide a fake the performance will be degraded | |
| 13:50:12 | efried | sahid: Is it ever the case that performance is *improved* by forcing resources to come from *separate* NUMA nodes? | |
| 13:50:25 | efried | ohh, this is the parallelism thing. | |
| 13:51:02 | mriedem | nvm | |
| 13:51:03 | mdbooth | mriedem: If you get a sec could you remove the procedural -2 on https://review.openstack.org/#/c/526346/ ? | |
| 13:51:24 | mriedem | done | |
| 13:51:29 | mdbooth | mriedem: Thanks | |
| 13:52:47 | sahid | efried: it's just that, the vCPUs threads and memory will be placed on the same host numa node, so yes the performance will be ever improved | |
| 13:53:08 | sahid | it's the only reason why numa exist | |
| 13:53:29 | efried | sahid: I understand how performance is improved by placing on the *same* node. I'm asking if it's important to be able to explicitly *separate*. | |
| 13:54:47 | efried | sahid: Because in the case we're talking about, --property hw:numa_nodes=N will spread your resources across *at most* N NUMA nodes. It could end up being anywhere from 1..N. (But it will never be >N) | |
| 13:54:51 | sahid | efried: it depends of the use-case and application. you can request only one. the point is to have cpu/memory on same node | |
| 13:54:52 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Make the nova-multiattach job non-voting temporarily https://review.openstack.org/560909 | |
| 13:54:53 | mriedem | efried: stephenfin: ^ | |
| 13:55:46 | efried | mriedem: +2 | |
| 13:56:16 | efried | sahid: So to my understanding, in this case, anything <N is a bonus. | |
| 13:56:16 | stephenfin | sahid: Right, but the CPU and memory will be on the same node. Again, we're not suggesting splitting an individual guest NUMA node | |
| 13:56:35 | efried | sahid: ...unless it's not. Which is what we're trying to ascertain. | |
| 13:56:51 | bauzas | efried: stephenfin: sahid: I think I have my answer tho | |
| 13:57:00 | efried | bauzas: Which is what? | |
| 13:57:34 | bauzas | efried: stephenfin: sahid: in my spec, I'll propose Placement to return all hosts accepting up to N NUMA nodes | |
| 13:57:35 | sahid | but it depends on the application. for example for realtime you don't want them to be separated, same story for zero-drop packets that because of some cpu improvements L2/L3 cache | |
| 13:57:54 | sahid | s/you don"t/you want | |
| 13:58:10 | bauzas | efried: stephenfin: efried: but then, the filter will continue to act as before and only accept hosts that equally match the number of nodes asked by the guest | |
| 13:58:23 | stephenfin | sahid: Say I have a guest with a PCI device. If I boot the instance with two NUMA nodes and place both guest NUMA nodes on the same host NUMA node | |
| 13:58:29 | bauzas | it's just we won't ask the filter to check hosts that don't have *at least* | |
| 13:58:40 | efried | bauzas: ++ but it must not only accept *hosts* - it must filter down *candidates* for that host. | |
| 13:58:54 | stephenfin | sahid: Assuming that host NUMA node is the same one that the PCI device is placed on, what would be wrong with that? | |
| 13:58:56 | bauzas | good correction | |
| 13:59:12 | efried | bauzas: Because you could (and usually will) get multiple candidates for the same host, some of which have N and some of which have <N | |
| 13:59:25 | stephenfin | efried: I do wish someone would write a glossary of placement terminology | |
| 13:59:39 | efried | bauzas: And sometimes you'll *only* get candidates with <N, in which case your filter will have to exclude that host. | |
| 13:59:39 | sahid | stephenfin: i understand what you are saying but it again it depends of the application used | |
| 13:59:42 | bauzas | efried: either way, Placement returns candidates to scheduler, but scheduler passes a list of hosts to the filter, right? | |
| 13:59:55 | efried | stephenfin: Ah, by candidate I mean "allocation candidate". | |
| 14:00:01 | stephenfin | sahid: Say for the non-realtime case | |
| 14:00:05 | sahid | or we need an option to say enforce that rule | |
| 14:00:22 | efried | stephenfin: technically the "allocation request" part of the result of GET /allocation_candidates | |
| 14:00:38 | bauzas | efried: say for example Placement returns 2 child RPs, each of them being a NUMA node of host1, it will only pass host1 to the NUMATopoFilter | |
| 14:01:20 | sahid | stephenfin: for realtime use case you want best effort cpu to run on different numa node than the realtime cpus are | |
| 14:01:22 | efried | stephenfin: There will be X candidates coming back from a GET /a_c request, but the total number of providers ("hosts") represented by those candidates can be <=X | |
| 14:01:46 | bauzas | efried: that's not a problem then, right? | |
| 14:02:07 | sahid | so bascially you are going to break realtime use case :) | |
| 14:02:16 | efried | sahid: No | |
| 14:02:32 | bauzas | efried: if host1 is having 2 nodes, and those 2 nodes are valid candidates for my query where resources1:VCPU=1&resources2:VCPU=1, I'll still pass to NUMATopoFilter only host1 | |
| 14:02:34 | efried | sahid: We're figuring out how to get N nodes when you ask for N nodes. | |
| 14:02:52 | sahid | efried: that seems reasonable | |
| 14:03:27 | jaypipes | efried, bauzas: #openstack-placement this conversation or mriedem is going to blow up. | |
| 14:03:49 | efried | jaypipes: We're talking about how nova is going to use placement | |
| 14:04:00 | stephenfin | efried: Oh, because the same host can be presented multiple ways? | |
| 14:04:08 | bauzas | jaypipes: the problem is that I'd love to see some NUMA experts chiming in | |
| 14:04:11 | efried | stephenfin: yes, exactly. | |
| 14:04:18 | stephenfin | efried: gotcha. Cheers | |
| 14:04:28 | bauzas | efried: again, I don't think there is a problem | |
| 14:04:41 | stephenfin | jaypipes: The damage should be limited to the west (?) coast. I'll be fine ;) | |
| 14:04:57 | bauzas | efried: the fact that placement is returning a list of candidates won't trample what the filter already does | |
| 14:05:15 | bauzas | if the filter restricts, cool | |
| 14:05:55 | bauzas | and again, if we want to make Placement restricting, let's do that *in a separate spec* | |
| 14:06:21 | efried | bauzas: don't think of numa nodes as candidates. Ignoring sharing for now, one allocation candidate (technically allocation request) will include resources from one host. The resources for each allocation request will be spread across one or more providers (numa nodes) in the tree. The filter will have to inspect each allocation request to see if the number of NUMA nodes represented equals the number of hw:numa_nodes in | |
| 14:06:23 | jaypipes | stephenfin: :) | |
| 14:06:57 | efried | bauzas: And remove the *allocation requests* where that's not the case. | |
| 14:07:36 | efried | bauzas: Now you'll still have X allocation requests representing results for Y hosts, where Y<=X | |
| 14:07:52 | bauzas | sec, otp | |
| 14:08:40 | efried | stephenfin or bauzas: wanna unblock the gate? https://review.openstack.org/#/c/560909/ | |
| 14:08:49 | stephenfin | efried: sure | |
| 14:09:12 | stephenfin | done | |
| 14:12:23 | mriedem | i see the problem | |
| 14:12:25 | mriedem | but don't understand it | |
| 14:12:30 | mriedem | https://review.openstack.org/#/c/554317/3/playbooks/legacy/nova-multiattach/run.yaml | |
| 14:12:36 | mriedem | removed ENABLE_UBUNTU_CLOUD_ARCHIVE=False right? | |
| 14:12:39 | mriedem | http://logs.openstack.org/17/554317/3/check/nova-multiattach/fd35a93/logs/local.conf.txt.gz | |
| 14:12:43 | mriedem | ENABLE_UBUNTU_CLOUD_ARCHIVE=False is in there | |
| 14:13:56 | mriedem | that's why it's blowing up | |
| 14:14:39 | mriedem | http://logs.openstack.org/17/554317/3/check/nova-multiattach/fd35a93/ara-report/result/ab8397a6-593e-43f5-a593-c2633a0e40de/ | |
| 14:14:53 | mriedem | idk what's up there but it looks like zuul isn't taking that change | |
| 14:15:00 | mriedem | mordred: you around for a zuul question? | |
| 14:16:38 | mriedem | there was a zuulv3 code deploy last night... | |
| 14:23:22 | mriedem | https://storyboard.openstack.org/#!/story/2001839 for anyone that cares | |
| 14:23:34 | mriedem | the job on master is picking up changes from the playbook in stable/queens | |
| 14:27:24 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Use Queens UCA for nova-multiattach job https://review.openstack.org/554317 | |
| 14:29:03 | bauzas | efried: back | |
| 14:29:20 | bauzas | IT person curse | |
| 14:29:41 | bauzas | my brother-in-law called me (while I'm at work!) for some personal issue with windows 10 | |
| 14:29:52 | bauzas | not kidding | |
| 14:30:06 | bauzas | one day, I'll explain to my family that : | |
| 14:30:16 | bauzas | #1 I have a real job even if working at home | |
| 14:30:26 | openstackgerrit | Jay Pipes proposed openstack/nova master: mirror nova host aggregate members to placement https://review.openstack.org/553597 | |
| 14:30:36 | bauzas | #2 working on IT doesn't mean I'm expert in windows-ishings | |
| 14:30:53 | dansmith | bauzas: can you help me defrag my hard drive? | |
| 14:31:03 | dansmith | bauzas: also, I think I have a virus | |
| 14:31:22 | dansmith | bauzas: what's your preferred program for video editing on my windows pc? | |
| 14:31:23 | bauzas | dansmith: my brother-in-law has no fucking idea of what 'defrag' means :p | |
| 14:31:46 | dansmith | bauzas: can you recommend a printer for laying ink on dead tree carcass since that's a thing I do | |