BFQv7 now v7r2, new releases of I/O disk scheduler are here!

[NicCo]

NEWS: it's been just released the new major version (v7) of BFQ (I/O disk scheduler used in nrj & nrjQL as default)

BFQv7 changelog:
http://algo.ing.unimo.it/people/paolo/d ... README.BFQ


It has been requested to me from "PastorDi" if I was going to update kernel 3.10 & 3.12 to BFQv7, start the testing...

Please, you can read from ROSA Forum, starting from:
http://forum.rosalab.ru/viewtopic.php?f ... 100#p24484


If You wish testing that thing ASAP, there are Kernel 3.10.28 & 3.12.9 with BFQv7, their release names end with "v7"
you should distinguish these versions ending with -1v7 or -69v7, they are in the same ABF folder of the main kernels

- Kernel-3.10.28-1v7 >>> https://abf.rosalinux.ru/kernels_3_10x/ ... uild_lists
- Kernel-3.10.28-69v7 >> https://abf.rosalinux.ru/kernels_3_10x/ ... uild_lists

- Kernel-3.12.9-1v7 >>> https://abf.rosalinux.ru/kernels_3_12x/ ... uild_lists
- Kernel-3.12.9-69v7 >> https://abf.rosalinux.ru/kernels_3_12x/ ... uild_lists

Availability:
- kernel-nrj-desktop and kernel-nrj-desktop-pae
- kernel-nrj-laptop and kernel-nrj-laptop-pae
- kernel-nrjQL-desktop and kernel-nrjQL-desktop-pae
- kernel-nrjQL-laptop and kernel-nrjQL-laptop-pae

Please, start testing kernels. we need to know if we must apply BFQv7 to the next kernel versions:
I suggest You to install the -1 and -1v7 version both concurrently, also the nrQL rels -69 and -69v7,
then make your testing, mainly make the comparisons between the kernel with BFQ v6 against v7


1' PC test (3.12.9 desktop on Rosa Marathon 64)

Code: Select all

$ uname -a 
Linux localhost.localdomain 3.12.9-nrjQL-desktop-69v7rosa.lts #1 SMP PREEMPT Sun Feb 2 15:40:42 CET 2014 x86_64 x86_64 x86_64 GNU/Linux

$ cat /sys/block/sda/queue/scheduler
noop deadline cfq [bfq]

$ inxi -F
System:    Host: localhost.localdomain Kernel: 3.12.9-nrjQL-desktop-69v7rosa.lts x86_64 (64 bit) 
           Desktop: KDE 4.8.3 Distro: ROSALinux 2012.0 turtle
Machine:   Mobo: ASUSTek model: M2NPV-VM version: 1.xx Bios: Phoenix version: ASUS M2NPV-VM 1401 date: 08/07/2008
CPU:       Dual core AMD Athlon 64 X2 6400+ (-MCP-) cache: 2048 KB flags: (lm nx sse sse2 sse3 svm) 
           Clock Speeds: 1: 3206.545 MHz 2: 3206.545 MHz
Graphics:  Card: nVidia C51PV [GeForce 6150] X.Org: 1.10.3 drivers: nv (unloaded: vesa,fbdev) Resolution: 1280x1024@60.0hz 
           GLX Renderer: Gallium 0.4 on llvmpipe GLX Version: 2.1 Mesa 7.11.2
Audio:     Card: Creative Labs SB Audigy driver: snd_emu10k1 Sound: ALSA ver: k3.12.9-nrjQL-desktop-69v7rosa.lts
Network:   Card: nVidia MCP51 Ethernet Controller driver: forcedeth 
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: 00:18:f3:e2:1d:f4
Drives:    HDD Total Size: 5001.0GB (17.4% used) 1: id: /dev/sda model: ST31000528AS size: 1000.2GB 
           2: id: /dev/sdb model: WDC_WD20EARS size: 2000.4GB 3: id: /dev/sdc model: WDC_WD20EARS size: 2000.4GB 
Partition: ID: / size: 50G used: 11G (23%) fs: ext4 ID: /home size: 366G used: 344G (94%) fs: ext4 
           ID: swap-1 size: 10.74GB used: 0.00GB (0%) fs: swap ID: swap-2 size: 10.74GB used: 0.00GB (0%) fs: swap 
RAID:      No RAID devices detected - /proc/mdstat and md_mod kernel raid module present
Sensors:   System Temperatures: cpu: 24.0C mobo: 24.0C 
           Fan Speeds (in rpm): cpu: 3391 sys-1: 0 
Info:      Processes: 267 Uptime: 1:30 Memory: 2298.8/3922.7MB Client: Shell (bash) inxi: 1.9.14 

2' PC test (3.12.9 laptop on Rosa Fresh 64)

Code: Select all

$ uname -a
Linux michele 3.12.9-nrj-laptop-1v7rosa #1 SMP PREEMPT Sun Feb 2 16:50:16 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ cat /sys/block/sda/queue/scheduler
noop deadline cfq [bfq] 

$ inxi -F
System:    Host: michele Kernel: 3.12.9-nrj-laptop-1v7rosa x86_64 (64 bit) 
           Desktop: KDE 4.11.4 Distro: RosaDesktop.Fresh 2012.1 belka
Machine:   System: Dell product: Precision M6600 version: 01
           Mobo: Dell model: 04YY4M version: A00 Bios: Dell version: A12 date: 08/09/2012
CPU:       Quad core Intel Core i7-2820QM CPU (-HT-MCP-) cache: 8192 KB flags: (lm nx sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx) 
           Clock Speeds: 1: 800.00 MHz 2: 800.00 MHz 3: 800.00 MHz 4: 800.00 MHz 5: 800.00 MHz 6: 2301.00 MHz 7: 2301.00 MHz 8: 1400.00 MHz
Graphics:  Card: NVIDIA GF104GLM [Quadro 3000M] X.Org: 1.14.5 drivers: nvidia,v4l Resolution: 1920x1080@60.0hz 
           GLX Renderer: Quadro 3000M/PCIe/SSE2 GLX Version: 4.4.0 NVIDIA 331.38
Audio:     Card-1: NVIDIA GF104 High Definition Audio Controller driver: snd_hda_intel 
           Card-2: Intel 6 Series/C200 Series Family High Definition Audio Controller driver: snd_hda_intel 
           Sound: Advanced Linux Sound Architecture ver: k3.12.9-nrj-laptop-1v7rosa
Network:   Card-1: Intel Centrino Ultimate-N 6300 driver: iwlwifi 
           IF: wlan0 state: down mac: 24:77:03:45:e5:90
           Card-2: Intel 82579LM Gigabit Network Connection driver: e1000e 
           IF: eth0 state: up speed: 100 Mbps duplex: half mac: d0:67:e5:41:81:87
Drives:    HDD Total Size: 750.2GB (38.1% used) 1: id: /dev/sda model: ST9750420AS size: 750.2GB 
Partition: ID: / size: 40G used: 7.2G (20%) fs: ext4 ID: /home size: 315G used: 135G (43%) fs: ext4 
           ID: swap-1 size: 21.48GB used: 0.00GB (0%) fs: swap 
RAID:      No RAID devices detected - /proc/mdstat and md_mod kernel raid module present
Sensors:   System Temperatures: cpu: 47.0C mobo: N/A gpu: 59C 
           Fan Speeds (in rpm): cpu: N/A 
Info:      Processes: 222 Uptime: 27 min Memory: 1195.2/16007.3MB Client: Shell (bash) inxi: 1.9.14

3' PC test (3.10.28 on Rosa Marathon 64 and OMV2013 64)

Code: Select all

With Kernel LTS 3.10, I had problems during the boot:
I need to investigate about the culprit and fix that
(I've noticed two complains during the build process)

4' PC test (3.12.9 laptop on OMV2013 64)

Code: Select all

[nicco@localhost ~]$ uname -a
Linux localhost.localdomain 3.12.9-nrjQL-laptop-69v7omv #1 SMP PREEMPT Sun Feb 2 17:06:07 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ cat /sys/block/sda/queue/scheduler
noop deadline cfq [bfq] 

[nicco@localhost ~]$ inxi -F
System:    Host: localhost.localdomain Kernel: 3.12.9-nrjQL-laptop-69v7omv x86_64 (64 bit) 
           Desktop: KDE 4.11.2 Distro: OpenMandrivaLinux 2013.0 oxygen
Machine:   Mobo: Acer model: JE02_PT version: V3.13(DDR3) Bios: Acer version: V3.13(DDR3) date: 12/23/2010
CPU:       Single core Intel Atom CPU N455 (-HT-) cache: 512 KB flags: (lm nx sse sse2 sse3 ssse3) 
           Clock Speeds: 1: 1666.00 MHz 2: 1666.00 MHz
Graphics:  Card: Intel Atom Processor D4xx/D5xx/N4xx/N5xx Integrated Graphics Controller 
           X.Org: 1.14.3 drivers: intel (unloaded: fbdev,vesa) Resolution: 1024x600@60.0hz 
           GLX Renderer: Gallium 0.4 on i915 ( GLX Version: 2.1 Mesa 9.2.1
Audio:     Card: Intel NM10/ICH7 Family High Definition Audio Controller driver: snd_hda_intel 
           Sound: Advanced Linux Sound Architecture ver: k3.12.9-nrjQL-laptop-69v7omv
Network:   Card-1: Broadcom BCM4313 802.11b/g/n Wireless LAN Controller driver: bcma-pci-bridge 
           IF: wlan0 state: up mac: 88:9f:fa:3a:ed:5c
           Card-2: Qualcomm Atheros AR8152 v1.1 Fast Ethernet driver: atl1c 
           IF: eth0 state: down mac: 1c:75:08:b9:08:51
Drives:    HDD Total Size: 250.1GB (17.8% used) 1: id: /dev/sda model: TOSHIBA_MK2565GS size: 250.1GB 
Partition: ID: / size: 25G used: 8.9G (39%) fs: ext4 ID: /home size: 201G used: 33G (17%) fs: ext4 
           ID: swap-1 size: 4.30GB used: 0.00GB (0%) fs: swap 
RAID:      No RAID devices detected - /proc/mdstat and md_mod kernel raid module present
Sensors:   System Temperatures: cpu: 51.0C mobo: N/A 
           Fan Speeds (in rpm): cpu: N/A 
Info:      Processes: 164 Uptime: 3 min Memory: 698.3/1993.1MB Client: Shell (bash) inxi: 1.9.16

[bvbfan]

New IO schedule works well, now i waiting new 3.13 kernel

Code: Select all

[anthony@Sony ~]$ inxi -F
System:    Host: Sony.Vaio Kernel: 3.12.9-nrj-laptop-1v7rosa i686 (32 bit) 
           Desktop: KDE 4.12.1 Distro: ROSALinux 2012.1 turtle                  
Machine:   System: Sony product: VPCYB1S1E version: C90076AD                    
           Mobo: Sony model: VAIO Bios: Insyde version: R0162Z7 date: 09/13/2011
CPU:       Dual core AMD E-350 (-MCP-) cache: 1024 KB flags: (lm nx pae sse sse2 sse3 sse4a ssse3 svm)                                                          
           Clock Speeds: 1: 1600.00 MHz 2: 1600.00 MHz                          
Graphics:  Card: Advanced Micro Devices [AMD/ATI] Wrestler [Radeon HD 6310]     
           X.Org: 1.14.5 drivers: ati,radeon Resolution: 1366x768@60.0hz        
           GLX Renderer: Gallium 0.4 on AMD PALM GLX Version: 3.0 Mesa 10.0.2   
Audio:     Card-1: Advanced Micro Devices [AMD/ATI] Wrestler HDMI Audio driver: snd_hda_intel                                                                   
           Card-2: Advanced Micro Devices [AMD/ATI] SBx00 Azalia (Intel HDA) driver: snd_hda_intel 
           Sound: Advanced Linux Sound Architecture ver: k3.12.9-nrj-laptop-1v7rosa                                                                             
Network:   Card-1: Qualcomm Atheros AR9285 Wireless Network Adapter (PCI-Express) driver: ath9k                                                                 
           IF: wlan0 state: up mac: 4c:0f:6e:d5:54:42                           
           Card-2: Qualcomm Atheros AR8131 Gigabit Ethernet driver: atl1c       
           IF: eth0 state: down mac: 78:84:3c:2b:b1:2b                          
Drives:    HDD Total Size: 320.1GB (30.0% used) 1: id: /dev/sda model: Hitachi_HTS54503 size: 320.1GB                                                           
Partition: ID: / size: 9.7G used: 6.2G (68%) fs: ext3 ID: /home size: 23G used: 13G (57%) fs: ext3                                                              
           ID: swap-1 size: 2.14GB used: 0.00GB (0%) fs: swap                   
RAID:      No RAID devices detected - /proc/mdstat and md_mod kernel raid module present                                                                        
Sensors:   System Temperatures: cpu: 68.0C mobo: 30.0C gpu: 68.0                
           Fan Speeds (in rpm): cpu: N/A                                        
Info:      Processes: 146 Uptime: 6 min Memory: 369.5/1619.8MB Client: Shell (bash) inxi: 1.9.14

[jclvanier]

Hi,
just tested 3.12.9-nrjQL-desktop-69v7omv with OmLx 2013.0-64 on an ux31 with ssd and didn't find any improvement in term of speed. Maybe a bit less quick, in average, than without BFQv7

show spoiler»

[NicCo]

Thanks to the collaboration of the BFQ staff (Arianna Avanzini, Paolo Valente),
we understood the reason of the boot problem issue with lts kernel 3.10 serie,
Arianna has sent me explaination and a further v7 patch valid with k >= 3.10.8
(Paolo Avanzini suggested me that BFQ v7r1, with other fixes, is really close)

In brief: with LTS Kernel 3.10, starting since 3.10.8,
kernel developers changed heavily the locking policy used during the memory device initialization,
they didn't adapted properly the code to support this new locking policy, result? blocked devices...

Code: Select all

%changelog

* Tue Feb 04 2014 Nicolo' Costanza <abitrules@yahoo.it> 3.10.28-1v7
+ Kernel 3.10.28 stable
- this is the second testing version with new BFQv7 disk I/O scheduler
- to fix the boot error, we add a fourth patch:
- 0004-block-Switch-from-BFQ-v7-for-3.10.0-to-BFQ-v7-for-3.10.8.patch
- -------------------------------------------------------------------

Finally we have LTS Kernel 3.10 with BFQv7, is booting faster and is working pretty fine
(perhaps, for ROSA and OpenMandriva, we have the first booting kernel 3.10 with BFQv7)

Code: Select all

$ uname -a
Linux localhost.localdomain 3.10.28-nrj-desktop-1v7rosa.lts #1 SMP PREEMPT Tue Feb 4 19:16:15 CET 2014 x86_64 x86_64 x86_64 GNU/Linux

$ cat /sys/block/sda/queue/scheduler
noop deadline cfq [bfq] 

$ inxi -F
System:    Host: localhost.localdomain Kernel: 3.10.28-nrj-desktop-1v7rosa.lts x86_64 (64 bit) 
           Desktop: KDE 4.8.3 Distro: ROSALinux 2012.0 turtle
Machine:   Mobo: ASUSTek model: M2NPV-VM version: 1.xx Bios: Phoenix version: ASUS M2NPV-VM 1401 date: 08/07/2008
CPU:       Dual core AMD Athlon 64 X2 6400+ (-MCP-) cache: 2048 KB flags: (lm nx sse sse2 sse3 svm) 
           Clock Speeds: 1: 3206.748 MHz 2: 3206.748 MHz
Graphics:  Card: nVidia C51PV [GeForce 6150] X.Org: 1.10.3 drivers: nv (unloaded: vesa,fbdev) Resolution: 1280x1024@60.0hz 
           GLX Renderer: Gallium 0.4 on llvmpipe GLX Version: 2.1 Mesa 7.11.2
Audio:     Card: Creative Labs SB Audigy driver: snd_emu10k1 Sound: ALSA ver: k3.10.28-nrj-desktop-1v7rosa.lts
Network:   Card: nVidia MCP51 Ethernet Controller driver: forcedeth 
           IF: eth0 state: up speed: 100 Mbps duplex: full mac: 00:18:f3:e2:1d:f4
Drives:    HDD Total Size: 5001.0GB (17.4% used) 1: id: /dev/sda model: ST31000528AS size: 1000.2GB 
           2: id: /dev/sdb model: WDC_WD20EARS size: 2000.4GB 3: id: /dev/sdc model: WDC_WD20EARS size: 2000.4GB 
Partition: ID: / size: 50G used: 11G (23%) fs: ext4 ID: /home size: 366G used: 344G (95%) fs: ext4 
           ID: swap-1 size: 10.74GB used: 0.00GB (0%) fs: swap ID: swap-2 size: 10.74GB used: 0.00GB (0%) fs: swap 
RAID:      No RAID devices detected - /proc/mdstat and md_mod kernel raid module present
Sensors:   System Temperatures: cpu: 21.0C mobo: 24.0C 
           Fan Speeds (in rpm): cpu: 3391 sys-1: 0 
Info:      Processes: 286 Uptime: 4 min Memory: 1538.8/3923.2MB Client: Shell (bash) inxi: 1.9.14 
utente /home $ 

Now ABF is busy with rebuilding kernel 3.12.9 (NAMESPACES fixed),
I hope to send to the rebuild 3.10.28 with BFQv7, tomorrow morning,
so, please, you must wait a bit...

[NicCo]

Hi,
just tested 3.12.9-nrjQL-desktop-69v7omv with OmLx 2013.0-64 on an ux31 with ssd and didn't find any improvement in term of speed. Maybe a bit less quick, in average, than without BFQv7

JeanClaud, your impressions are right!

Hi,
bad news: we just found a bug in BFQ-v7, which, according to our experiments, causes a little loss of throughput on SSDs (about ten percent with the heaviest workloads).

Good news: we already fixed it, and are revising and testing the BUGFIX-patch.

Sorry for this bug,
Paolo

[rolf]

..
JeanClaud, your impressions are right!

Hi,
bad news: we just found a bug in BFQ-v7, which, according to our experiments, causes a little loss of throughput on SSDs (about ten percent with the heaviest workloads).

Good news: we already fixed it, and are revising and testing the BUGFIX-patch.

Sorry for this bug,
Paolo

I see you're very busy with kernel development but, as my ROSA installation is on an ssd, I'll wait for you to do this patch, thanks.

[NicCo]

BFQv7r1

During this week-end, I'm going to prepare new kernels 3.10.29 & 3.12.10,
these will be equipped with the newest and improved BFQv7r1, plus will contain few further feature patches.


I have none SSD to test with it, so I need help with testing:
I ask you, JeanClaud Vanier, you that noticed and informed me about the performance issue with your Laptop and SSD, to try this new version 3.12.10, so you can confirm us that this issue for you has gone out

Naturally, if others amongst You have SSD equipped PCs should focus testing mainly with these devices:
then, please, report here!



I'm collaborating, sharing infos with the BFQ staff, and below is the text that I've received from Paolo, just this morning

Hi,
after a great effort on both my and Arianna's side, we are proud to release a thoroughly tested BFQ-v7r1 after a relatively short time.

The main bug we fixed in v7, which we found after noting some throughput anomalies with an SSD, also made a little additional miracle: this fix further reduced latencies in some cases where there were still margins for improvement. In fact, as you will see from the new version of the result page we just published, now BFQ achieves, e.g., the lowest-possible application start-up times with most of the background workloads considered in our tests. I strongly suggest you to have a look at these new results at the usual URL:
http://algogroup.unimore.it/people/paol ... esults.php
The page now contains only plots, with BFQ compared against CFQ, DEADLINE and NOOP, and tests executed on many different devices. We are currently running latency tests also with video playing. We will publish results as soon a we collect them.

The main bug we fixed in v7 is mainly technical in nature, so I prefer no to bore you on that in this email. If you are curious, have a look at the changelog. This time Arianna prepared even more patches:
. BFQ-v7r1 is available for kernels from 3.0.0
. The patchset for 3.10.8+ is available as well (I remind you that some little modifications are needed in BFQ to let it work properly with this series of stable kernels)
. All the incremental patches you can dream of are probably available (for 3.0.0 onward)

I am really tired, so I hope I did not make some mistake somewhere. Apart from that, I do hope you will enjoy this revision of v7,
Paolo

bye, NicCo

[NicCo]

BFQv7r2
Since few mins I have received new BFQ v7r2 patches for kernels:
I am already preparing new kernel versions with this thing inside...

The first will be the Kernel 3.12.11, then will follow the LTS 3.10.30:
now I'm running an internal build and test, then I'll send the srpms

[ANNOUNCE] BFQ-v7r2 for 3.0.0 - 3.13.0, plus 3.10.8+

Paolo Valente
A bfq-iosched@googlegroups.com
Oggi alle 7:03 PM

Hi,
you may have the impression that we entered a frenetic code-development
phase with BFQ. Well, you are right. Why?

Because at last it seems that we have found the time to pack BFQ for
submission to lkml. And, while breaking down BFQ into a set of logically
distinct patches (for review), we have bumped into a small piece of BFQ
that we could not describe clearly. Finally, we have understood,
embarrassingly, that we let the heuristic for soft real-time
applications perform one important step in a confused way ...

So we fixed that, and here is the result: v7r2. Besides being
conceptually clear, the new version of this step also provided little
additional benefits in terms of responsiveness and latency for soft
real-time applications. If you are interested into more details, I
pasted an excerpt of the changelog at the end of this email.

Thanks to the indispensable contribution of Arianna, patches are again
available for a countless number of kernel versions.

Finally, I took the opportunity to further update the test-result page
with the results for v7r2, obtained using the just-released new version
of the benchmark suite:
http://www.algogroup.unimo.it/people/pa ... esults.php
In particular, this page now also contains a link to an extra result
page, with responsiveness results for two more applications and, above
all, frame-drop-rate results for our video-playing tests. I do suggest
you to have a look at these results, if only to better know what you are
putting in your kernels

Paolo

Excerpt from the changelog:

BUGFIX/IMPROVEMENT. One of the requirements for an application to be
deemed as soft real-time is that it issues its requests in batches, and
stops doing I/O for a well-defined amount of time before issuing a new
batch. Imposing this minimum idle time allows BFQ to filter out I/O-bound
applications that may otherwise be incorrectly deemed as soft real-time
(under the circumstances described in detail in the comments to the
function bfq_bfqq_softrt_next_start()). Unfortunately, BFQ could however
start counting this idle time from two different events: either from the
expiration of the queue, if all requests of the queue had also been already
completed when the queue expired, or, if the previous condition did not
hold, from the first completion of one of the still outstanding requests.
In the second case, an application had more chances to be deemed as soft
real-time.
Actually, there was no reason for this differentiated treatment. We
addressed this issue by defining more precisely the above requirement for
an application to be deemed as soft real-time, and changing the code
consequently: a well-defined amount of time must elapse between the
completion of *all the requests* of the current pending batch and the
issuing of the first request of the next batch (this is, in the end, what
happens with a true soft real-time application). This change further
reduced false positives, and, as such, improved responsiveness and reduced
latency for actual soft real-time applications.