On 6/13/19 1:20 AM, Jan Kara wrote: > On Wed 12-06-19 12:36:53, Srivatsa S. Bhat wrote: >> >> [ Adding Greg to CC ] >> >> On 6/12/19 6:04 AM, Jan Kara wrote: >>> On Tue 11-06-19 15:34:48, Srivatsa S. Bhat wrote: >>>> On 6/2/19 12:04 AM, Srivatsa S. Bhat wrote: >>>>> On 5/30/19 3:45 AM, Paolo Valente wrote: >>>>>> >>>> [...] >>>>>> At any rate, since you pointed out that you are interested in >>>>>> out-of-the-box performance, let me complete the context: in case >>>>>> low_latency is left set, one gets, in return for this 12% loss, >>>>>> a) at least 1000% higher responsiveness, e.g., 1000% lower start-up >>>>>> times of applications under load [1]; >>>>>> b) 500-1000% higher throughput in multi-client server workloads, as I >>>>>> already pointed out [2]. >>>>>> >>>>> >>>>> I'm very happy that you could solve the problem without having to >>>>> compromise on any of the performance characteristics/features of BFQ! >>>>> >>>>> >>>>>> I'm going to prepare complete patches. In addition, if ok for you, >>>>>> I'll report these results on the bug you created. Then I guess we can >>>>>> close it. >>>>>> >>>>> >>>>> Sounds great! >>>>> >>>> >>>> Hi Paolo, >>>> >>>> Hope you are doing great! >>>> >>>> I was wondering if you got a chance to post these patches to LKML for >>>> review and inclusion... (No hurry, of course!) >>>> >>>> Also, since your fixes address the performance issues in BFQ, do you >>>> have any thoughts on whether they can be adapted to CFQ as well, to >>>> benefit the older stable kernels that still support CFQ? >>> >>> Since CFQ doesn't exist in current upstream kernel anymore, I seriously >>> doubt you'll be able to get any performance improvements for it in the >>> stable kernels... >>> >> >> I suspected as much, but that seems unfortunate though. The latest LTS >> kernel is based on 4.19, which still supports CFQ. It would have been >> great to have a process to address significant issues on older >> kernels too. > > Well, you could still tune the performance difference by changing > slice_idle and group_idle tunables for CFQ (in > /sys/block/<device>/queue/iosched/). Changing these to lower values will > reduce the throughput loss when switching between cgroups at the cost of > lower accuracy of enforcing configured IO proportions among cgroups. > Good point, and seems fair enough, thank you! Regards, Srivatsa VMware Photon OS