Friday, 23 September 2016

BFS 502, linux-4.7-ck5

With the fix for the last of the freezes with BFS497 becoming clearer and a number of other minor issues being attended to, such as build failures and minor improvements accumulating, I'm releasing a new BFS that combines all into yet another release, which should be the last of the releases for the 4.7 kernel.

BFS by itself:
4.7-sched-bfs-502.patch

-ck patches with BFS:
4.7-ck5

In addition to the update to BFS, this -ck release is the first in a very long time to include a patch from another developer - the Throttled background buffered writeback v7 patch by Jens Axboe. This makes a massive difference to a system's ability to read files, open new applications etc. under heavy write loads in my testing and is a change which I believe is essential and will eventually make its way into the mainline kernel.

The changes to BFS 502 are as follows:
 
bfs497-build_other_arches.patch
bfs497-no_smtload_avg.patch
bfs497-recognise_nodes2.patch
bfs497-revert-othercpufreq.patch
bfs497-fix_smt_nonice.patch 

  • A build fix for building on other architectures (notably ARM).
  • Simplifying the load measurement on SMT machines reported to cpufreq - trying to account for load on the SMT sibling is unnecessary as each core will run at the speed of the most loaded sibling anyway on any existing hardware.
  • A fix for detecting CPUs on other NUMA nodes and setting their locality correctly.
  • Not trying to signal CPU load to cpufreq on other CPUs when tasks migrate - this was leading to the hangs and there is enough rescheduling for cpufreq to get the load later on.
  • A build fix for when SMT_NICE is not configured.

Enjoy!
お楽しみ下さい
-ck

Posted by at
Labels: , , ,

6 comments:

  1. Anonymous24 September 2016 at 00:22

    @CK, post-factum, and other testers:
    Con, you mention the "Throttled background buffered writeback" patch now, that I got to know from post-factum's repo months ago. I use BFS (and mostly with Alfred Chen's mods) together with the BFQ for years now. post-factum has a little patch in his repo, in order to make BFQ 'wbt-aware'. As you gave the link to the lkml entry above:
    How do you judge/ consider the reply from Paolo Valente, from the BFQ project?

    I'm interested in your opinion,
    thank you in advance and best regards,
    Manuel Krause

    ReplyDelete
    Replies
    1. ck24 September 2016 at 07:11

      I never found BFQ to be of great benefit while this throttled buffered writeback patch's effect is dramatic.

      Delete
    2. Mike25 September 2016 at 00:38

      In contrary to Con I use BFQ with happyness ;), because I/O troughput is much better and even if there is much I/O, the response is nearly at once.
      Measured some large copy operations to USB disk drives, BFQ is always on physical speed limit of the drive/interface, but CFQ slows down after a while (end result: 70% of BFQ) and not to mention the slow feeling of the desktop.
      BFQ and BFS are here a good team. ;)

      In response to the patch from Jens Axboe the author from BFQ has written his results: https://groups.google.com/forum/#!topic/bfq-iosched/R-iwTR57_BU. Conclusion "Unfortunately results are quite bad, as latency seems even to increase a little bit". He responded to the mailing list with test results, but as usual no comment from Jens.

      Another general problem was mentioned on the mailing list: interactiveness during large writes. https://groups.google.com/forum/#!topic/bfq-iosched/M2M_UhbC05A

      "The root of this nasty problem is that I/O requests of unlucky processes are simply not issued. ... Unlucky processes just get blocked, even for seconds, on each read or write attempt. If they have a lot of reads/writes to make, then it’s pure starvation for them. An I/O scheduler cannot help in any way, as it can do its job only on the read/write requests that it does receive." But please read the full explantation there. Paolo already has some patches as solution for this problem, but not ready for the official kernel.
      So my question to Con, could this be done within the process scheduler (BFS/CFS) or is this done elsewhere in the kernel? (noob here ;) )

      Thanks and keep up your good work.

      Remark: With zen-kernel 4.7.4, BFS497 and governor schedutil my "idle" top values are 0,6 compared to 0,1..0,2 on 4.6. Btw. idle means here KDE and some apps like firefox are open, but now activty for a long time.

      Regards sysitos

      Delete
    3. ck25 September 2016 at 08:15

      Spinning disk vs SSD?

      Delete
    4. Anonymous26 September 2016 at 03:44

      Thank you for sharing your experiences and knowledge.
      Flame wars are hopefully not ahead on here, even if Jens Axboe keeps to not reply. ^^
      I don't benchmark, but keep an eye on the expected results and timings of my everyday's use, continuously.
      Currently, I'm testing the BFS502+pending with BFQ and WBT.

      BR, Manuel Krause

      Delete
    5. ck1 October 2016 at 07:22

      Interesting. Maybe I'll start including it myself since the default is optional anyway.

      Delete

Subscribe to: Post Comments (Atom)