Hard lock-ups with bfq and bfq-mq about bfq-mq HOT 3 CLOSED

algodev-github commented on August 24, 2024

Hard lock-ups with bfq and bfq-mq

from bfq-mq.

Comments (3)

paolo-github commented on August 24, 2024

Il giorno 20 lug 2017, alle ore 13:47, monotykamary ***@***.***> ha scritto: I wasn't too sure where to post this issue, but I'll post it here since the patches I format are directly from this repository. I've have formatted patch snapshots of bfq-mq and tested them with the ck-patchset and the stock kernel. In testing 4.11-ck1 and 4.11-ck2 with bfq-mq, hard lockups occurred when the disk was idle or very close to idle. I have not tested for latency, but system ran as expected (with no problems) only if I am running multiple make threads or an application with moderate I/O load.

Hi, thanks for reporting these issues. Unfortunately, bfq-mq is just a dev branch, used to support the development of bfq for blk-mq. Currently it is based against 4.13-rc1, and, to avoid a maintenance burden that I cannot afford, I have not made any bfq-mq-v4.11 branch :( So, I can only guess the likely cause of these failures: bugs in the the middle bfq-mq version that you happened to use to make upper patches.

My workload at the time mainly consisted of testing patches and compiling kernels. With the ck-patchset and bfq-mq, as soon as a compile job was done and after a random amount of time, the system locks up. I assumed that this was a scheduler issue related with my CPU, so I left it as is. However, I saw similar cases when testing the stock kernel with the patch from 4.11.1 onwards, but it happened somewhat rarely so I didn't pay much attention to it. I experienced the same issue recently with the stock Arch Linux kernel 4.12.1 onwards when enabling bfq, and once more on kernel 4.12.2 + patch to the current commit (+ patch to include block merge for 4.13). It is to the point where it locks up before I finish starting up my usual applications.

So, you are sure you have ALL the commits in 4.13-rc1? I'm asking because 4.13-rc1 contains important fixes for bfq that didn't make it to 4.12 (because it was too late when they were ready).

mq-deadline and kyber work with no problems along with all the single-queue I/O schedulers so it doesn't seem like a hardware issue regarding my HDD. Out of source bfq has worked flawlessly. I don't think I've made any issues in formatting the patch

What patches exactly? Aren't you talking about bfq in mainline now (and not any out-of-tree bfq)?

since it applies very cleanly on git and on build, although I could be very wrong. The hard lockups will not respond to sysrq keys and there are no journal logs. I'm a bit troubled as to what to do to get more information on this.

…

Machine: Device: portable System: Dell product: Inspiron 3421 Mobo: Dell model: Inspiron 3421 v: A01 BIOS: Dell v: A01 date: 11/05/2012 CPU: Dual core Intel Core i5-3317U (-HT-MCP-) cache: 3072 KB clock speeds: max: 2600 MHz 1: 800 MHz 2: 800 MHz 3: 800 MHz 4: 800 MHz Graphics: Card-1: Intel 3rd Gen Core processor Graphics Controller Card-2: NVIDIA GK107M [GeForce GT 640M] Display Server: X.Org 1.19.3 drivers: nvidia,intel Resolution: ***@***.*** OpenGL: renderer: Mesa DRI Intel Ivybridge Mobile version: 4.2 Mesa 17.1.5 Audio: Card Intel 7 Series/C216 Family High Definition Audio Controller driver: snd_hda_intel Sound: Advanced Linux Sound Architecture v: k4.12.2-1-ARCH Network: Card-1: Broadcom Limited BCM43142 802.11b/g/n driver: bcma-pci-bridge IF: N/A state: N/A mac: N/A Card-2: Realtek RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller driver: r8169 IF: enp9s0 state: down mac: e0:db:55:8d:dc:af Card-3: Qualcomm Atheros AR9271 802.11n driver: ath9k_htc IF: wlp0s29u1u2 state: N/A mac: N/A Drives: HDD Total Size: 1000.2GB (34.4% used) ID-1: /dev/sda model: TOSHIBA_MQ01ABD1 size: 1000.2GB Partition: ID-1: / size: 904G used: 310G (37%) fs: ext4 dev: /dev/sda4 ID-2: swap-1 size: 12.88GB used: 0.00GB (0%) fs: swap dev: /dev/sda3 Sensors: System Temperatures: cpu: 48.0C mobo: N/A Fan Speeds (in rpm): cpu: N/A — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

from bfq-mq.

monotykamary commented on August 24, 2024

Many thanks for the reply!

So, I can only guess the likely cause of these failures: bugs in the
the middle bfq-mq version that you happened to use to make upper
patches.
So, you are sure you have ALL the commits in 4.13-rc1? I'm asking
because 4.13-rc1 contains important fixes for bfq that didn't make it
to 4.12 (because it was too late when they were ready).

I've only minimally added the commits related to the block layer, but specifically not all of the commits in 4.13-rc1 which I see now is quite a big oversight on my part.

If you are sure that you do have all 4.13-rc1commits in your kernel,
then the only solution for you, according to what your report, is to
use netconsole. This would of course help all the community too. If
you are willing to proceed, then please continue our discussion on the
official bfq group:
https://groups.google.com/forum/#!forum/bfq-iosched

Since I didn't add all the commits from 4.13-rc1 and that my method to build the kernel has issues and limitations, I will start from scratch and build the repository from git. I'm not too familiar with netconsole as I normally just have one machine (laptop) running Linux, but do have some spare PC boxes to use and will report whatever I can find in the group. I do apologize for the inconvenience.

from bfq-mq.

paolo-github commented on August 24, 2024

Il giorno 20 lug 2017, alle ore 15:02, monotykamary ***@***.***> ha scritto: Many thanks for the reply! So, I can only guess the likely cause of these failures: bugs in the the middle bfq-mq version that you happened to use to make upper patches. So, you are sure you have ALL the commits in 4.13-rc1? I'm asking because 4.13-rc1 contains important fixes for bfq that didn't make it to 4.12 (because it was too late when they were ready). I've only minimally added the commits related to the block layer, but specifically not all of the commits in 4.13-rc1 which I see now is quite a big oversight on my part.

No no, sorry, I have not been precise: I did mean all BLOCK-LAYER commits. I just wanted to warn you on having possibly overlooked some commit. Thanks, Paolo

…

If you are sure that you do have all 4.13-rc1commits in your kernel, then the only solution for you, according to what your report, is to use netconsole. This would of course help all the community too. If you are willing to proceed, then please continue our discussion on the official bfq group: https://groups.google.com/forum/#!forum/bfq-iosched Since I didn't add all the commits from 4.13-rc1 and that my method to build the kernel has issues and limitations, I will start from scratch and build the repository from git. I'm not too familiar with netconsole as I normally just have one machine (laptop) running Linux, but do have some spare PC boxes to use and will report whatever I can find in the group. I do apologize for the inconvenience. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

from bfq-mq.

Hard lock-ups with bfq and bfq-mq about bfq-mq HOT 3 CLOSED

Comments (3)

Related Issues (2)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent