Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-23
20:35:29 jaypipes mriedem: you'll be able to smell it in the morning too.
20:35:29 melwitt ok, I see. based on this, I think maybe we shouldn't try to proxy. it doesn't seem like it would buy much even for users
20:35:34 mriedem hi-o
20:35:37 jaypipes lol
20:35:54 mriedem melwitt: well you probably want to run that by mgagne
20:36:06 melwitt and penick
20:36:43 melwitt yeah, I'm just speculating here. will definitely want to talk to them and see if they would be ok with a placement CLI that can fan out to aggregate RPs
20:37:12 melwitt or if being able to set the aggregate metadata is really that valuable to them
20:37:27 jaypipes mriedem: how will melwitt get ahold of penick, though?
20:37:39 jaypipes mriedem: he is a tough cookie to track down.
20:37:40 mriedem paper airplane?
20:37:45 jaypipes hehe
20:37:47 melwitt yeah, that part will be tough. I don't know him that well
20:38:01 jaypipes melwitt: you can set five upon him.
20:38:37 jaypipes for some reason I always think of He-Man's Attack Cat when I picture Five...
20:38:45 mriedem melwitt: it is important to mgagne because they allow non-admin users access to set host aggregate allocation ratios via the API
20:38:55 melwitt jaypipes: lol battlecat, that's awesome
20:38:56 mriedem that's why the RBAC need was big in placement for mgagne
20:39:04 jaypipes melwitt: battlecat, right :)
20:39:16 melwitt I had a battlecat, so cool
20:40:19 melwitt jaypipes: have you watched that "toys that made us" show on netflix? they have one that has the he-man toy line. I found it really interesting
20:40:44 melwitt mriedem: ahhh ok
20:42:08 jaypipes melwitt: hmm, no... sounds like it would be good to watch, though!
20:42:40 melwitt there's only like 4 episodes, I watched em all
20:44:12 melwitt the more I think about it, I'm like proxying isn't so terrible either is it? being that we're already mirroring aggregates anyway. setting the ratios would be a small extra step, it seems. but if placement has RBAC, then would mgagne be happy... hrm.
20:49:45 jaypipes all that hard work I did this morning from 3:30am - 8am in reducing my browser tab count by 63 tabs has been slowly destroyed again.
20:50:13 melwitt you were working at 3:30am??
20:51:58 mriedem cdent: if you have people internally that still care about these https://review.openstack.org/#/c/552190/ https://review.openstack.org/#/c/549067/ you might want to kick them to update them for stein
20:52:14 cdent mriedem: i've kicked them several times to no avail
20:52:23 mriedem shall i drop the abandon hammer then?
20:52:29 mriedem that way you're not the bad guy
20:52:51 cdent mriedem: meh, I'd let them ride a bit longer, might still be a chance
20:53:42 jaypipes melwitt: yeah, couldn't sleep.
20:53:59 mriedem overcommitting a dedicated pcpu... https://review.openstack.org/#/c/599957/ seems...odd
20:54:08 jaypipes BTW, I have COMPLETELY failed in my sean-k-mooney spellchecker powers today.
20:54:11 mriedem isn't that an oxymoron?
20:54:45 mriedem oxymoron = overcommitted dedicated pcpu
20:54:48 melwitt thinking about that hurts my brain
20:54:54 jaypipes mriedem: yeah, it is, and I chatted with tpatil about that in Denver
20:55:14 melwitt definitely sounds contradictory
20:55:31 jaypipes mriedem: mostly they just need the whole "allow a single compute host to have dedicated stuff and non-dedicated stuff on the same box" thing
20:55:48 jaypipes mriedem: I doubt Tushar will follow up on that spec.
20:55:53 mriedem and then PCPU inventory has an allocation_ratio>1.0?
20:56:48 mriedem b/c this spec https://review.openstack.org/#/c/599957/ is all about many new config options
20:56:54 mriedem which kinda sucks
21:00:38 melwitt they're saying two of the options (cpu_dedicated_set, cpu_shared_set) come from a different spec though, `Standardize CPU resource tracking`
21:02:22 melwitt so only the cpu_pinning_allocation_ratio would be new. which really I guess is meaning pcpu_allocation_ratio, whereas the existing cpu_allocation_ratio technically means vcpu_allocation_ratio?
21:03:18 melwitt so that they separate handling of vcpu vs pcpu
21:05:38 melwitt also interesting, it says based on the prereq spec https://review.openstack.org/#/c/555081 that PCPU inventory will be created with hardcoded allocation ratio of 1.0 and they want to be able to change it/overcommit it. so wouldn't that just be a call to the placement API?
21:06:45 melwitt but I guess they want to be able to set it the same way as is possible for VCPU
21:06:55 melwitt via nova.conf
21:36:09 mriedem edleafe: all sorts of API gross for you to munch on here https://review.openstack.org/#/c/580336/4
21:41:09 cfriesen I think my question about the "overcommit PCPUs" idea is what does it buy you that a low CPU overcommit ratio (with non-dedicated cpus) wouldn't?
21:46:40 sean-k-mooney jaypipes: haha was there a partical pharse that exausted the spellchecking ablity today :)
21:48:53 sean-k-mooney cfriesen: over commiting pinned cpus i think would be less objectionable but the fact we choose hw:cpu_policy=dedicated|shared and not hw:cpu_policy=pinned|floating makes me dislike the idea
21:49:16 edleafe mriedem: gee thanks!
21:52:29 cfriesen sean-k-mooney: once you have more than one instance using a cpu, it's shared. I don't see what this would buy us compared to just using a shared CPU
21:54:45 sean-k-mooney cfriesen: well i very limited cases it may improve you performance as pinning will result in numa affinity for leagacy reasons but i would personally prefer hw:cpu_policy=share + hw:numa_nodes=1
21:55:42 cfriesen sean-k-mooney: agreed. And if you were using hugepages you'd get the numa affinity anyways.
21:56:24 sean-k-mooney cfriesen: also since we are going to be using the dedictate_cpu_set for allocating realtime cpus i think this is likely to break that also
21:57:00 cfriesen wait...how is a realtime cpu different from a regular dedicated cpu?
21:58:36 sean-k-mooney cfriesen: realtime we set the "nice" value or whatever the priority values is on linux to realtime so it does not get premented if you have a realtime kernel
21:58:51 sean-k-mooney cfriesen: we dont set the tread prioity for dedicated cpus
22:02:33 cfriesen sean-k-mooney: that's what I thought, just making sure. if you've already got a "dedicated" cpu with nothing else running on it, what's the benefit of making the vcpu task realtime?
22:02:56 cfriesen (unless the host hasn't properly moved all kernel work off that cpu)
22:03:09 sean-k-mooney basiclly ^
22:03:25 sean-k-mooney or there is some backgound process that is on the host that is not confied properly
22:03:30 sean-k-mooney but very little
22:05:05 cfriesen but if the host hasn't moved kernel work off that cpu, and you run the qemu task as realtime, don't you risk priority inversion anyways if the guest is doing a busy-loop and never letting other tasks run?
22:05:59 jaypipes sean-k-mooney: no, just distracted generally :)
22:06:01 sean-k-mooney cfriesen: one if its actully a kernel thread then the kernel will run it if it needs too
22:06:31 sean-k-mooney cfriesen: second if its a user tread the kernel can rescudle it i think if the vm is in a busy loop
22:06:34 mriedem melwitt: can we abandon https://review.openstack.org/#/c/509042/ or are there plans to update that?
22:07:07 sean-k-mooney cfriesen: i think we tell people dont use this unless you have set up your host properly for realtime workloads and properly isolated the cores
22:07:21 melwitt mriedem: I'd like to update it but we need allocation ownership concepts in placement else it's moot
22:07:33 mriedem so is anyone driving that dependency?
22:07:37 sean-k-mooney cfriesen: at least i tell people do ues the realtime feature unless you have set up the host properly
22:08:44 cfriesen sean-k-mooney: on hosts with the RT kernel a bunch of kernel things get run in schedulable threads
22:08:55 melwitt mriedem: no, just saying, that's why it's stuck
22:09:21 melwitt and maybe, I guess I could ask jaypipes because I thought I saw mention of the idea of an owner attribute in some other spec
22:09:25 sean-k-mooney cfriesen: on https://review.openstack.org/#/c/599957 i suggested just adding a hw:cpu_policy=pinned which would pin the vm to one of the shared cpu set cores instead. does that sound better then over commiting dedicated cpus to you?
22:09:25 mriedem ok, so....if it's stuck, and no one is working on unstucking it, and it's not high enough priority to are, should we just abandon
22:09:34 mriedem *care
22:09:51 openstackgerrit Merged openstack/nova-specs master: Dynamically find releases for move-implemented-specs https://review.openstack.org/592628
22:10:08 sean-k-mooney cfriesen: oh ya but you have to use isolcpus too if you useing the realtime core extra specs in nova correctly
22:10:10 cfriesen sean-k-mooney: I think you'd need to pin each vCPU in the VM to one of the shared cpu set cores.
22:10:25 sean-k-mooney cfriesen: yes that is what i was suggesting
22:10:46 melwitt mriedem: for the record, I care about it a lot but I can't argue that allocation ownership in placement is a priority given everything else that's going on. I can abandon it on that basis
22:10:57 cfriesen sean-k-mooney: isolcpus means no scheduling, so only works with explicit pinning and one vcpu per pcpu.
22:11:12 sean-k-mooney cfriesen: yep
22:11:21 cfriesen sean-k-mooney: yeah, so pinning to shared cpu set cores makes more sense to me
22:18:33 sean-k-mooney cfriesen: ok that comment is in there spec but while i kind of get this usescase i also think its not a great one.
22:20:25 cfriesen it's purely a small performance optimization compared to just using "shared"
22:21:08 cfriesen which is valid, but it makes the resource tracking really messy
22:21:20 sean-k-mooney cfriesen: well in tushars case they want to have more over subsction with the same perfromce i think
22:21:40 cfriesen sean-k-mooney: their performance document is comparing against "shared"
22:22:15 sean-k-mooney yes but they are not comparing against shared with hw:numa_nodes=1 are they
22:22:21 cfriesen nope.
22:22:21 sean-k-mooney also where is the doc?
22:22:28 cfriesen linked at the bottom of the spec

Earlier   Later