On 25 April 2017 at 23:08, Tejun Heo <t...@kernel.org> wrote: > On Tue, Apr 25, 2017 at 11:49:41AM -0700, Tejun Heo wrote: >> > I have run a quick test with your patches and schbench on my platform. >> > I haven't been able to reproduce your regression but my platform is >> > quite different from yours (only 8 cores without SMT) >> > But most importantly, the parent cfs_rq->runnable_load_avg never >> > reaches 0 (or almost 0) when it is idle. Instead, it still has a >> > runnable_load_avg (this is not due to rounding computation) whereas >> > runnable_load_avg should be 0 >> >> Heh, let me try that out. Probably a silly mistake somewhere. > > This is from the follow-up patch. I was confused. Because we don't > propagate decays, we still should decay the runnable_load_avg; > otherwise, we end up accumulating errors in the counter. I'll drop > the last patch.
Ok, the runnable_load_avg goes back to 0 when I drop patch 3. But i see runnable_load_avg sometimes significantly higher than load_avg which is normally not possible as load_avg = runnable_load_avg + sleeping task's load_avg Then, I just have the opposite behavior on my platform. I see a increase of latency at p99 with your patches. My platform is a hikey : 2x4 cores ARM and I have used schbench -m 2 -t 4 -s 10000 -c 15000 -r 30 so I have 1 worker thread per CPU which is similar to what you are doing on your platform With v4.11-rc8. I have run 10 times the test and get consistent results schbench -m 2 -t 4 -s 10000 -c 15000 -r 30 Latency percentiles (usec) 50.0000th: 255 75.0000th: 350 90.0000th: 454 95.0000th: 489 *99.0000th: 539 99.5000th: 585 99.9000th: 10224 min=0, max=13567 With your patches i see an increase of the latency for p99. I run 10 times the test too and half tests show latency increase like below schbench$ ./schbench -m 2 -t 4 -s 10000 -c 15000 -r 30 Latency percentiles (usec) 50.0000th: 216 75.0000th: 295 90.0000th: 395 95.0000th: 444 *99.0000th: 2034 99.5000th: 5960 99.9000th: 12240 min=0, max=14744 > > Thanks. > > -- > tejun
