Is your feature request related to a problem? Please describe.
Run a shell script that does a lot of computational work and doesn't block or only very rarely. Right now this script will receive a penalty from the scheduler because the vcpu executing the script will use up all of its quantum (of QoS class Interactive) without ever blocking. This might eventually lead to a situation where the script running in the foreground ends up competing with Utility/Background QoS class vcpus. We don't necessarily want that to happen. It's technically correct because the script isn't cooperative and violates the QoS model assumption that members of high QoS classes like Interactive are I/O bound rather than compute bound.
Nevertheless, we're running the script "interactively" as a foreground app and thus the user's expectation is that this script receives a good chunk of the available CPU cycles. Additionally since the script is the foreground app, the user can always terminate it if it hogs the machine too much.
Describe the solution you'd like
We should lengthen the quantum of the foreground process/process group by 50% to 100% to reduce the likeliness that we trigger the penalty. Additionally that would give that process more leeway when here and there it needs to do some more heavy computations without reducing the CPU cycles that it receives.
Describe alternatives you've considered
An alternative or maybe an additional approach would be to replace the penalty system with a "pull up" system. Meaning that instead of reducing the priority of a high(er) priority compute bound guy, that we'd check from time to time whether a vcpu has been sitting a long time in the ready queue and that we boost its priority if that's the case. The priority boost would then decay over time.
Is your feature request related to a problem? Please describe.
Run a shell script that does a lot of computational work and doesn't block or only very rarely. Right now this script will receive a penalty from the scheduler because the vcpu executing the script will use up all of its quantum (of QoS class Interactive) without ever blocking. This might eventually lead to a situation where the script running in the foreground ends up competing with Utility/Background QoS class vcpus. We don't necessarily want that to happen. It's technically correct because the script isn't cooperative and violates the QoS model assumption that members of high QoS classes like Interactive are I/O bound rather than compute bound.
Nevertheless, we're running the script "interactively" as a foreground app and thus the user's expectation is that this script receives a good chunk of the available CPU cycles. Additionally since the script is the foreground app, the user can always terminate it if it hogs the machine too much.
Describe the solution you'd like
We should lengthen the quantum of the foreground process/process group by 50% to 100% to reduce the likeliness that we trigger the penalty. Additionally that would give that process more leeway when here and there it needs to do some more heavy computations without reducing the CPU cycles that it receives.
Describe alternatives you've considered
An alternative or maybe an additional approach would be to replace the penalty system with a "pull up" system. Meaning that instead of reducing the priority of a high(er) priority compute bound guy, that we'd check from time to time whether a vcpu has been sitting a long time in the ready queue and that we boost its priority if that's the case. The priority boost would then decay over time.