On 6/12/19 1:36 PM, 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. > > Greg, do you have any thoughts on this? The context is that both CFQ > and BFQ I/O schedulers have issues that cause I/O throughput to suffer > upto 10x - 30x on certain workloads and system configurations, as > reported in [1]. > > In this thread, Paolo posted patches to fix BFQ performance on > mainline. However CFQ suffers from the same performance collapse, but > CFQ was removed from the kernel in v5.0. So obviously the usual stable > backporting path won't work here for several reasons: > > 1. There won't be a mainline commit to backport from, as CFQ no > longer exists in mainline. > > 2. This is not a security/stability fix, and is likely to involve > invasive changes. > > I was wondering if there was a way to address the performance issues > in CFQ in the older stable kernels (including the latest LTS 4.19), > despite the above constraints, since the performance drop is much too > significant. I guess not, but thought I'd ask :-) > > [1]. https://lore.kernel.org/lkml/8d72fcf7-bbb4-2965-1a06-e9fc177a8938@xxxxxxxxxxxxx/ This issue has always been there. There will be no specific patches made for stable for something that doesn't even exist in the newer kernels. -- Jens Axboe
