On 23-Jan 10:52, Peter Zijlstra wrote: > On Tue, Jan 22, 2019 at 06:18:31PM +0000, Patrick Bellasi wrote: > > On 22-Jan 18:13, Peter Zijlstra wrote: > > > On Tue, Jan 15, 2019 at 10:15:05AM +0000, Patrick Bellasi wrote: [...] > > If a task is not clamped we execute it at its required utilization or > > even max frequency in case of wakeup from IO. > > > > When a task is util_max clamped instead, we are saying that we don't > > care to run it above the specified clamp value and, if possible, we > > should run it below that capacity level. > > > > If that's the case, why this clamping hints should not be enforced on > > IO wakeups too? > > > > At the end it's still a user-space decision, we basically allow > > userspace to defined what's the max IO boost they like to get. > > Because it is the wrong knob for it. > > Ideally we'd extend the IO-wait state to include the device-busy state > at the time of sleep. At the very least double state io_schedule() state > space from 1 to 2 bits, where we not only indicate: yes this is an > IO-sleep, but also can indicate device saturation. When the device is > saturated, we don't need to boost further. > > (this binary state will ofcourse cause oscilations where we drop the > freq, drop device saturation, then ramp the freq, regain device > saturation etc..) > > However, doing this is going to require fairly massive surgery on our > whole IO stack. > > Also; how big of a problem is 'supriouos' boosting really? Joel tried to > introduce a boost_max tunable, but the grandual boosting thing was good > enough at the time. Ok then, I'll drop the clamp on IOBoost... you right and moreover we can always investigate for a better solution in the future with a real use-case on hand. Cheers. -- #include <best/regards.h> Patrick Bellasi
