BFS 0472 Sync-up patch for 4.7 kernel is available

BFS 0472 Sync-up patch for 4.7 kernel is available after spending the last weekend to put all sync-up patches upon bfs 0472 and fixed the suspend/resume issue on one of my notebook.

Based on quick sanity tests, the cpufreq api deployment issue in 0470 has been fixed. And the performance for low workload is better than previous release.

Enjoy this and wait for the incoming vrq patch. :)


BR Alfred

BFS 0470 Sync-up patch for 4.7 kernel is available

My porting of BFS 0470 Sync-up patch for 4.7 kernel is available.
It contains all-sync-up works from release to release and mainly the sync-up work for 4.7 kernel. It's working and suspend/resume also seems good considing the cpu hot-plug api updates from the upstream.

Have fun with this "pure" BFS patch with 4.7 and I am working on -vrq branch.

BR Alfred

Heads up! Performance regression over several release

Performance regression over several releases from 4.3 to 4.6 is observed，under low workload(50% workload) on smt machine(without SMT_NICE config)

Just re-test the 4.3-vrq kernel, 4.5-vrq and bfs/vrq/test on 4.6, the sanity tests show that major performance regression occurs, saying 20~30 more seconds in a 7mins test. The pure bfs of 4.6 is impacted badly, about 50% more time taken(11mins).

More sanity tests for different versions of kernel during 4.3 to 4.5 are still on the way to find out where to looking at firstly. There could be more than one cause for the regression based on the sanity result current have. I will keep you updated.

BR Alfred

Updates:

After investigation,  there are three factors contribute to the regression.

1. Regression from release to release, there are minor regression recorded from 4.4 to 4.5 and 4.5 to 4.6 using default CFS setting. Unfortunately, nothing could be done from BFS/VRQ scheduler's perspective.
2. Interactivity default on setting which is introduced in BFS 0466(4.5), which contribute about 50% of the regression.
3. cpufreq_trigger() API introduced in 4.6 was not properly deployed in BFS0470. I have a debug load to improve this API deployment,  but it's not  robust enough to go public.

As 4.7 was released this week, I'd like to address this regression issue in 4.7. There are major changes about scheduler code in this release, and it will take longer to port/sync the codes. Good news is it's about 25% finished, the first bfs 4.7 kernel is up and running.

v4.6_0470_test5 patch released

v4.6_0470_test5 patch is available which fix a bug in the last two test patches(test3 and test4), so it's highly recommended to upgrade to this test5 patch if you are on test branch.

PS, it's not include the debug patch for Eduardo, I'm still waiting for the feedback then decide how to tune the codes.

BR Alfred

v4.6_0470_test4 patch for testing & 4.6 Sanity test raw data

v4.6_0470_test4 patch is available which has only one big update
- low workload performance regression fix

Highly recommend to update to this version if you are on -test branch.

And the 4.6 sanity tests are done which run on cfs/bfs/vrq/vrq-test, the raw data can be downloaded here, if you are interesting in

BR Alfred

BFS/VRQ on Raspberry Pi 2

When it is at 4.1 release, the Raspberry PI 2 used to have stable issue with VRQ patch, which cause it hang after about 1 day uptime. I have to run it with -gc patch for 7*24 usage.

In this release, it happens that I have to debug the -vrq stable issue and I decided to try -vrq again on rpi2. Till now, my Raspberry PI 2 7*24 box has been up with 4.6 BFS/VRQ patch for almost 12 days. No scheduler related kernel debug warming/error in can be found so far. So it is considered stable.

The -vrq patch of 4.6 can be cleanly apply on rpi kernel tree and no additional patch is needed. Have fun with these wonderful SoCs with BFS/VRQ scheduler.

BR Alfred