New vrq patch for v4.3

I'd like to wait for v4.3.1 before official release new gc and vrq code, but it looks like a test patch would be welcome before that.

Here it comes, please download the vrq_v4.3_0465_2.patch from bitbucket download page and it contains the bfs 0465 rebase and part3 of task caching commit in it. Feel free to git it a try and report back.

PS, I got feedback from a user who report vrq with wine gaming has better experience like mouse movement etc. It turns out the initial idea of vrq about reducing grq lock sessions helps.

BR Alfred

GC and VRQ branch update for v4.3

GC branch has been updated at bitbucket and github, gc version has bumped to v4.3_0463_1 with a minor v4.3 sync-up update. The all-in-one patch file is at gc_v4.3_0463_1.patch.

VRQ branch has been also updated at bitbucket and github, the version is v4.3_0463_1_vrq0, new commit for vrq will be added upon it. All-in-one patch file is at gc_v4.3_0463_1_vrq0.patch.

Have fun with 4.3 kernel.

BR Alfred

gc_v4.3_0463_0 patch released

The "zero" version of -gc patch for 4.3 kernel has been released at bitbucket download page. It's a single patch file you can apply upon vanilla kernel source tree. I'm working on the rest of commits on -gc branch and waiting for upstream patch updates for v4.3 before pushing the -gc branch to public git.

Pls report back if you have issue with the patch, I'm still looking at the minor changes and may bump the version to "one" when it's official released.

BR Alfred

-gc and -vrq update for v4.2.4

There are API updates in v4.2.4, so here comes the -gc and -vrq branch updates.

You can checkout the latest code from bitbucket or github for gc branch. Main sync-up commit is e8d2e33 bfs: [Sync] sync-up with v4.2.4 

For -vrq branch, besides the sync-up commit 2f4a9ac bfs: [Sync] sync-up with v4.2.4, there is a bug fix commit 7de8ad5 bfs/vrq: Fix preemptible code in sys_sched_yield(), this commit is to address smp_processor_id() in preemptible [00000000] code error in sys_sched_yield(). Vrq branch is updated at bitbucket and github.

BR Alfred

Consider cache in task scheduling Part 2

In this part, let's look at the first factor of the task caching -- the cpu cache size. Talking about cache, there is a fighting between Intel and AMD about the cache size in their cpu design years ago. Intel tends to have large cpu cache size while AMD uses less. I remembered one of AMD's explain is software for gaming doesn't use large cache size. I'm kind of agree that.

IMO, cpu cache size, especially the LLC(Last Level Cache) size determined the hardware capacity of how many data can be cached for cpu. And look at this in another way, giving a sequence of tasks switching, the cpu cache size determined how long the data of a task can be kept in cache. For system with large workload, large number of tasks are running at the same time, cpu with larger cache size will help for keeping task's data in cache than cpu with less cache size. For system workload for short response time, like gaming, large cache size doesn't help much. So, AMD is right for this, but large cache size design is good for common workload usage, not just for the workload like gaming.

Task scheduling should take cpu cache size(llc size) into account. In the latest 4.2 vrq branch, there is a new commit implements the first version of code change, which aware of llc cache size of cpu and auto adjust the cache_scost_threshold(cache switch cost threshold) by it. (For the concept of cache switch cost threshold, please reference to Part 1). Here is the brief of what it has been done.

1. export a scheduler interface to cacheinfo(drivers/base/cacheinfo.c) as a call back once cacheinfo is ready.
2. implement a simple linear formula to auto cache_scost_threshold adjustment.

• Now this formula is considered based on intel core2 cpu topology and 64bit kernel. Every 512KB LLC size increase CACHE_SCOST_THRESHOLD value by 3.
• For 32bit kernel, consider 32bit use less data/instruction size, every 256KB LLC size increase CACHE_SCOST_THRESHOLD value by2, but I don't have 32bit systems to prove this yet.
• The new cpu topology like smt is not yet be considered in the formula, because there are bounces in the benchmark result when SMT enable, so it's hard to compare the result of different CACHE_SCOST_THRESHOLD value.

3. A kernel boot parameter "cache_scost_threshold" is introduced, it can be used for manually assigning the CACHE_SCOST_THRESHOLD value to scheduler if

• cacheinfo is not available in your arch(like arm, most?) or
• the simple linear formula is not covering your cpu topology and you want to find out the best value of it.

It's still at its first version, in next version, I'd like to complete the formula to cover the SMT topology.

... to be continued (Part 3)

VRQ branch for 4.2 release

Just want to post a notice that vrq branch for 4.2 is released, at both bitbucket and github, and it's version is tagged v4.2_0463_2_vrq1.

What's new:
1. Combine a few commits into VRQ solution and bump it's version

3edb4d4 bfs/vrq: VRQ solution v0.6

2. Rename rq->nr_interruptible to rq->nr_uninterruptible, to keep sync with mainline code

dcdc064 bfs/vrq: Instroduce rq->nr_uninterruptible 

3. Task caching scheduler part 2, there will be an individual post for it

8f5e7d2 bfs/vrq: cache scost threshold adjust by llc size 

 

Meanwhile, I'm trying to improve performance for SMT/using task caching property,  unfortunately not every try turns out a positive result, as usual. Anyway, have fun with this new 4.2 vrq release.

BR Alfred

gc_v4.2_0463_2 released

As title, just two new updates in this release

1. Remove resched_closest_idle() as planned in previous release post. I haven't got the feedback yet, but considering more reports are coming, both calls are removed at this release. The modified commit is

da50716 bfs: Full cpumask based and LLC sensitive cpu selection, v4

2. Fix update_cpu_load_nohz() redefine error when undefine CONFIG_NO_HZ_COMMON, this is a missing for the 4.2 sync up, the modified commit is

75fd9b3 bfs: [Sync] 4.2 sync up v2

New -gc branch can be found at bitbucket and github. An all-in-one patch includes all bfs related changes(*NOT* all commits in -gc branch) is also provided. 

Have fun with this new -gc release, and -vrq branch update is in-coming.

BR Alfred