00:24:27 <sommerfeld> 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.  
00:25:34 <sommerfeld> 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...
04:10:09 <jclulow> sommerfeld: Are you running the bhyve process in a zone?
04:12:09 <jclulow> 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.
04:20:58 <sommerfeld> yes, in a zone.
04:39:39 <jclulow> sommerfeld: Have you looked at yield_to_vcpu()
05:24:03 <sommerfeld> yes, and smt_need_kick
10:09:28 <jlevon> jclulow: it's already nearly a wash, doing that would make it *definitely* better to just turn off smt.
10:10:43 <jlevon> 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.
22:58:39 <sommerfeld> 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.