Saturday, November 26, 2016

VRQ 0.89c released

VRQ 0.89c was released with

1. Introduce sched_rq_queued_masks, which made the run queue looking for higher policy queued task from other run queue firstly.
2. Fix unexpected design intention when creating new tasks and fix a hang issue enabling this new code.

I have decided to make a last-minute callback of planned task policy fairness feature commit, as it introduced a dead-lock scenario, by fixing this dead-lock, it leads to other side effects. It may need different solution for task policy fairness.

The cause of the cpu c-state issue has been found, it's the cpufreq_trigger callback.  It seems it also related to schedutil and intel cpufreq governor issues. It's time to solve it once for all.

Above two are in the to-do list in 0.89d. Although there are less commits in these release, but the sanity test also shows visible improvement in all kinds of workload.

code are available at
and also

all-in-one patch also available.

Enjoy it! :)

Wednesday, November 16, 2016

VRQ 0.89b released

VRQ 0.89b is released with

1. Fix low workload regression comparing to previous vrq release by not trying to pick tasks from other run queue when cpu is scaling.
2. Follow cpu affinity order when pick tasks from other run queue.
3. Fix long existed wrong run queue scaling value when run on performance governor or exit from dynamic governor.

With all above changes, this release show better sanity performance than any other previous vrq releases. Next release will be focus on task policy fairness.

code are available at
and also

all-in-one patch also available.

Enjoy it, :)

Thursday, November 10, 2016

VRQ 0.89a released

VRQ 0.89a is released which mainly fix the imbalance cpu usage issue. Now all cpu can run at 100%, and no issue found in daily usage.

Also, there are other code changes/refines in scheduler core, but I afraid it is not so visible.

For this release, sanity kernel compilation tests also show there is noticeable improvement comparing the previous vrq release at 100%~300% workload. At 50% workload, a small regression is found in the 4 cores system, a debug patch already gets it back to the same level of the previous vrq, but I'd like it to be well test on other systems before officially commit it.

I am happy with the sanity test results, it show this new release of vrq already better than previous release, and there are several performance improvement idea not yet implemented.

Have fun with this release and expect the next. :)

BR Alfred

PS: code are available at
and also

Wednesday, November 2, 2016

VRQ 0.89 test branch released

VRQ at its beginning is to reduce grq(global run queue) lock access as much as possible. In previous release of VRQ, it was trying to get rid of grq lock access hot spots and create grq lock free code path. With the recently introduced skip list queue data structure, grq could be wiped out completely, and it will be happened in this and the incoming release of VRQ.

The immediately question will be whether it is base on MuQSS by CK? Answer is NO. It actually divided from an early commit of 4.8 -vrq branch. The reasons why not based on MuQSS are
1. Different skip list implementation.
2. There are still many sync-up and feature commits need to be picked up from previous -vrq branch.
3. Different rules to be followed and different routine implementation.
4. Codes are more controlable when work on a familiar code base.

So here comes this new release of VRQ with the below changes

* Totally remove the global rq structure, per cpu run queue has its own skip list to hold the running tasks on this run queue and be accessed by rq->lock(which is existed in previous version of VRQ).

* Update task_access_lock/unlock(...) strategy for grq/rq data structure changes.

* Update set_task_cpu() logic and usage as it has to follow the principle rules, 1. don't use set_task_cpu() for blocked tasks, let ttwu to solve out. 2. Setting task's cpu means to change the cpu/rq which task resided on.

* Update set_cups_allowed_ptr() logic and usage when task is queued or running on wrong cpu.

* Update cpu hot-plug api implementation as tasks now reside on per cpu run queue instead of a global run queue. And makes cpu on/off-line and suspend/resume work more reliable.

* Remove unused code such as sticky task, because by putting prev task to per rq skip list is natural stick/cache.

* more to be listed.

It's not done yet, so this is called release 0.89, the major known issue is the imbalanced cpu loading, on two cpus system, most system workload will be on cpu0. On a quad cores system, it becomes better but some cores are still not running at 100% cpu usage. This is because a very simple version of __schedule() and TTWU() is using in this release, not fantastic feature is deployed yet.

With the above known issue/limitation, it's not suitable to use this release in a production environment. This release is aim to demonstration the foundation routine changes adapting to per cpu run queue and verify no major system broken occurs. Then in next release(0.9), fix for imbalance cpu loading and scheduler performance improvement could be added.

You are encouraged to test this VRQ release, don't looking at performance, it sucks due to the known limitation. But please looking for miss behaviors of system or suspected kernel log comparing to previous VRQ release.

Code is available at
and also

Enjoy it.

BR Alfred