v4.7_0472_test0 patch released
There is no new code for this first test patch, not even include the debug patches(for 4.6) in the previous post.
Base on the sanity test result, the new code changes in the test patch improve throughput on non-SMT cpu, in all kinds of workload scenarios, just like the sanity result in 4.6 release(v4.6_0470_test4 patch for testing & 4.6 Sanity test raw data). But for SMT cpus, throughput regression are recorded.
So the next important item for -test branch would be fix the regression on SMT cpus.
Enjoy this first -test patch for 4.7 and wait for the next -test release, :)
What should I say: Yesterday morning I 've had the first TOI resume failures since months. Of course there are many possible causes, including random hardware indisposition. I'll keep watching it but won't hammer suspend/resume cycles now.ReplyDelete
Besides this described one, everything works fine on here with this -test0 patch.
For this kernel I've reduced NORMAL_POLICY_CACHED_WAITTIME to (4), also for my previous VRQ2 testing. With this setting interactivity is very good, flash video playback in Firefox is also good. But to be honest: It's gotten hard to compare it with normal VRQ2. Subjectively, I'd say with this setup -test0 is a little superior for interactivity, when dealing with higher I/O plus swapping plus video-playback.
My kernel 4.7.0 setup includes: Your VRQ2-test0, my TOI-forward-port, most recent writeback-throttling code extracted from post-factum's tree, BFQ with all the recent commits that would lead to v8r3.
The previously tested VRQ2 kernel only differed in your patch.
BR, you're really doing good work!
With the sentence "you're really doing good work!" I wanted to express, that this version behaves better than the previous ones, and that it's much better than the last 4.6.x one I've used, so far without a working BFQ v8 implementation (as kernel 4.7 came out earlier).Delete
BR, Manuel Krause
Thanks for testing. I am testing -test1, will be released in these two days.Delete