Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-12
11:07:22 efried which would be tough to code
11:07:40 artom efried, has that configparser thing been fixed? I see you rechecked the NUMA LM patches
11:07:44 sean-k-mooney ok i see
11:07:47 efried artom: yes
11:07:52 artom Sweet
11:07:54 efried artom: carefully curating the gate atm
11:08:04 efried sean-k-mooney: no, we have to do them sequentially, because we always want to try the pcpu ones first for a given host.
11:08:04 artom Yep, thanks for that
11:08:28 efried but we do one right after the other
11:08:35 efried and collect all the candidates
11:08:41 efried then send them all down to the filter.
11:08:58 sean-k-mooney right
11:09:24 sean-k-mooney i assume we only add host form the second query if its not in the first?
11:09:36 sean-k-mooney or do we just let the filter handel that
11:09:41 efried I don't think we're being that careful about it
11:09:51 sean-k-mooney actully it does not matter
11:09:54 efried right
11:10:19 sean-k-mooney the filter work on host not allocation candiates
11:11:01 sean-k-mooney so it will pass the host if it fit and fail it if it does not
11:11:23 sean-k-mooney and the host will only support one of the two with pinning
11:12:15 sean-k-mooney a host can have VCPU and PCPUs but if it returns pcpu allocation then that is what we will need to use
11:14:42 sean-k-mooney efried: by the way this https://review.opendev.org/#/c/679656/ is the numa live migration job. it not a pirortiy today but i would like to merge that before RC1 to get it running nightly once artoms code is fully merged.
11:15:04 sean-k-mooney it add the nova-nfv-multi-numa-multinode job
11:15:16 efried sean-k-mooney: ack, please ask about it next week
11:15:33 sean-k-mooney yep will do
11:16:45 efried sean-k-mooney: https://review.opendev.org/#/c/681358/ os-vif release ack pls?
11:17:01 openstackgerrit Balazs Gibizer proposed openstack/nova master: Do not query allocations twice in finish_revert_resize https://review.opendev.org/678827
11:17:09 sean-k-mooney mels patch ya ill ack that now
11:20:04 openstackgerrit Stephen Finucane proposed openstack/nova master: fixup! Add support for translating CPU policy extra specs, image meta https://review.opendev.org/681719
11:20:29 stephenfin efried, sean-k-mooney, alex_xu, bauzas: Before I squash that back and fix the tests, want to give that the once over ^ ?
11:20:55 alex_xu yup, checking now
11:21:09 efried ...
11:25:02 alex_xu ah, that is smart
11:26:00 alex_xu stephenfin: works for me
11:26:43 sean-k-mooney checking
11:27:01 efried stephenfin: looks good, couple of comments in there.
11:29:58 luyao sean-k-mooney: Hi, if you get time, could you help look vpmem xml again? thanks ( we discussed before about the numa requiring and alignment, and got a consensus about them)
11:30:29 luyao https://review.opendev.org/#/c/678455/
11:31:51 sean-k-mooney efried: also commented. we should not use update as i noted inline
11:32:22 stephenfin efried: I shouldn't have pushed those mox patches through last night either. Sorry :(
11:32:42 efried no biggie stephenfin
11:33:00 efried they're all going to get kicked out here in a minute
11:33:05 sean-k-mooney luyao: yep i have it open efried pinged me earlier
11:33:29 sean-k-mooney im just going to grab coffe then ill review the vpmem seriese in full starting with the xml patch
11:33:31 stephenfin cool. I switched to -2 on the bottom one to make it clear
11:33:36 luyao sean-k-mooney: hah, thanks
11:35:00 stephenfin On the other hand, once that lands mox is basically gone. It's only been four years \o/
11:35:19 efried sean-k-mooney, stephenfin: It's not important enough to spend a bunch of time on, but am I crazy about .update()?
11:35:38 stephenfin in relation to...?
11:35:42 efried a psum is a psum
11:36:16 efried the way you're doing it I guess you're not replacing one that's already there, whereas .update would (redundantly) replace
11:36:33 stephenfin I need a link
11:36:45 efried I guess python probably isn't smart enough to skip
11:36:48 sean-k-mooney oh maybe i miss understood
11:36:52 efried so yeah, I guess the way you're doing it is going to be more efficient
11:36:56 efried but the result will be the same
11:37:01 sean-k-mooney i though stephen was filtering the allocation candiate but he is not
11:37:10 efried just question of whether you want fewer LOC I guess
11:37:23 efried stephenfin: https://review.opendev.org/#/c/681719/1/nova/scheduler/manager.py@197
11:37:30 sean-k-mooney update is fine for the summaries
11:37:51 sean-k-mooney i would prefer if we filtered this however
11:37:53 sean-k-mooney Draft
11:38:17 sean-k-mooney alloc_reqs.extend(alloc_reqs_fallback)
11:38:45 efried sean-k-mooney: filter it how?
11:38:59 stephenfin efried: tomato tomato. As you say, it doesn't matter
11:39:07 stephenfin I'm happy to go with '.update()'
11:39:10 sean-k-mooney is that the set of alloction candiates
11:39:13 efried we explicitly can't skip the ones we already have PCPUs for
11:39:20 efried that's the whole point
11:39:35 efried ... I think
11:39:42 sean-k-mooney it would be better not to pass 2 allcoation candiate for any given host
11:39:49 efried because the filter might kick out the PCPU ones
11:40:18 sean-k-mooney efried: we need to make sure if the filter passes we use the PCPU allocation candiate not the VCPU one
11:40:28 sean-k-mooney if we have two we need extra code to handel that
11:40:37 efried That's already covered I thought
11:40:43 sean-k-mooney where
11:40:43 efried because the candidates are in order per host
11:41:06 efried .extend is O(1) (I think) so we're just taking a mem hit by not filtering. Whereas if we loop through and try to filter, we're O(N).
11:41:07 sean-k-mooney if they are ordered and we take the first one then ok
11:41:11 efried y
11:41:24 efried we noodled this out with gibi earlier I think
11:41:27 stephenfin To do that, we'd need to inspect each entry in alloc_reqs_fallback, pull out the resource provider ID, and check if it exists in alloc_reqs
11:41:34 stephenfin and I think they're ordered so it won't matter
11:41:53 sean-k-mooney efried: exthend is fine if we have odering and can rely on it
11:42:11 sean-k-mooney i just was not aware that was a thing
11:42:16 stephenfin I could do this (I think)
11:42:35 efried stephenfin: I'd rather leave it I think
11:42:47 sean-k-mooney ya i think its fine
11:42:51 efried unless some good reason to do otherwise
11:42:52 stephenfin alloc_reqs.extend([a for a in alloc_reqs_fallback if a['allocations'][path to rp UUID] not in provider_summaries)
11:43:17 efried still O(N)
11:43:20 sean-k-mooney im just trying to make sure we dont pick the wrong allcoatin candiage and end up using VCPUs when we have pinned cores on a host that has both
11:43:22 stephenfin Nah, it's simpler as-is and avoids us doing extra work on what could be a very big list
11:43:23 stephenfin Yup
11:43:41 efried ++
11:43:41 stephenfin sean-k-mooney: Remember, the NUMATopologyFilter will prevent that
11:43:58 sean-k-mooney stephenfin: no the numa toplogy filter will only pass or fail a host
11:44:08 sean-k-mooney stephenfin: it has no say over the allocation candiates
11:44:18 sean-k-mooney so it will pass or fail both
11:44:35 sean-k-mooney filters today work on host not allocation candiates

Earlier   Later