vm-bhyve
vm-bhyve copied to clipboard
churchers
Add real/idle-time priority options.
Adds new high_ and low_priority options (enable with "yes") which use rtprio 31 and idprio 0 (lowest of the high, and highest of the low) to move the executing bhyve into the real or idle-time scheduling buckets. Options override preferring highest priority specified.
I had a need to run one vm with rtprio and had a look at existing PRs before working on the source myself, so I found this one :)
Is there a specific reason not to allow custom rt or id priorities here?
I had a need to run one vm with
rtprioand had a look at existing PRs before working on the source myself, so I found this one :) Is there a specific reason not to allow custom rt or id priorities here?
I second this. I think that we should allow custom rt/id priorities.
My guess is that this would be splitting hairs; the current fixed values (the highest (0) of the idle, and lowest (31) of the real-time priorities) let you move the bhyve instance above/below "normal" nice ranges, so everything else you're competing with is likely from the kernel.
That said, there certainly is nothing technically preventing it (save the caveat in man rtprio).
Real-life scenario where I need that: I have a routing/firewalling VM ("owning" all NICs with PCI passthrough), and on the same machine is a poudriere jail already running on idprio -- still it can cause a lot of load, probably also in (kernel) ZFS code. The only way my networking keeps responsive is setting the routing VM on rtprio.
I'm not discounting the use case for idprio / rtprio (which is why I submitted the PR in the first place) ... I'm just wondering if there is a real need for fine-grained (within idprio or rtprio ranges) settings. Moving things into rtprio 31 (lowest rt) or idprio 0 places them above or below most tasks.
That said, feel free to modify this code to accept a level [0..31] rather than on/off for "high_priority" or "low_priority" and submit it as a PR; I'll close this one and point to that one.