so I think smt_acquire() needs to work harder to elbow threads off the sibling CPU. use case: my development system, while running a single VM and a nightly build. system is using FSS; nightly build is run as a project "batch", which is configured with project.cpu-shares=(privileged,0,none) which means that its threads should get out of the way of anything else if anything else needs the cpu.

while the build is running, the bhyve process for the VM burns a bunch of cpu, but the VM is not responsive *unless* I put it in a processor set containing a sibling pair of cpus...

sommerfeld: Are you running the bhyve process in a zone?

If not, there's probably at least one other piece: I believe we are supposed to be punting the sibling thread for security reasons but we only do that if the _zone_ is different between threads in a pair, rather than _processes_. Which is something we should probably fix.

yes, in a zone.

sommerfeld: Have you looked at yield_to_vcpu()

yes, and smt_need_kick

jclulow: it's already nearly a wash, doing that would make it *definitely* better to just turn off smt.

the whole thing should just be removed imo unless somebody actually wants to go and rewrite basically all the scheduler. turning off smt is just better.

jclulow: really it should be up to the system administrator of the host to determine where the boundaries are. (in my case I want a clean way to turn it off...). zoneid isn't bad as a default. uid/creds would be another reasonable boundary.