Hi,
In my test, I found some issues when try bfq with xfs.
The test basically just set the disk's scheduler to bfq,
create xfs on top of it, mount fs and write something,
then umount the fs. After several rounds of iteration,
I can see different calltraces appeared.
For example, the one which happened frequently:
Jan 03 11:35:19 linux-mainline kernel: XFS (vdd): Mounting V5 Filesystem
Jan 03 11:35:19 linux-mainline kernel: XFS (vdd): Ending clean mount
Jan 03 11:35:19 linux-mainline kernel: XFS (vdd): Unmounting Filesystem
Jan 03 11:35:19 linux-mainline kernel: XFS (vdd): Mounting V5 Filesystem
Jan 03 11:35:19 linux-mainline kernel: XFS (vdd): Ending clean mount
Jan 03 11:35:19 linux-mainline kernel: BUG: unable to handle kernel
paging request at 0000000000029ec0
Jan 03 11:35:19 linux-mainline kernel: IP: __mod_node_page_state+0x5/0x50
Jan 03 11:35:19 linux-mainline kernel: PGD 0 P4D 0
Jan 03 11:35:19 linux-mainline kernel: Oops: 0000 [#1] SMP KASAN
Jan 03 11:35:19 linux-mainline kernel: Modules linked in: bfq(E)
joydev(E) uinput(E) fuse(E) af_packet(E) iscsi_ibft(E)
iscsi_boot_sysfs(E) snd_hda_codec_generic(E) crct10dif_pclmul(E)
crc32_pclmul(E) xfs(E) ghash_clmulni_intel(E) libcrc32c(E)
crc32c_intel(E) pcbc(E) snd_hda_intel(E) snd_hda_codec(E)
snd_hda_core(E) snd_hwdep(E) snd_pcm(E) ppdev(E) aesni_intel(E)
snd_timer(E) aes_x86_64(E) crypto_simd(E) snd(E) glue_helper(E)
cryptd(E) pcspkr(E) virtio_balloon(E) virtio_net(E) parport_pc(E)
parport(E) soundcore(E) i2c_piix4(E) ext4(E) crc16(E) mbcache(E) jbd2(E)
virtio_console(E) virtio_rng(E) virtio_blk(E) ata_generic(E) ata_piix(E)
ahci(E) libahci(E) floppy(E) ehci_pci(E) qxl(E) serio_raw(E)
drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E)
fb_sys_fops(E) sym53c8xx(E) scsi_transport_spi(E) button(E) libata(E)
Jan 03 11:35:19 linux-mainline kernel: ttm(E) drm(E) uhci_hcd(E)
ehci_hcd(E) usbcore(E) virtio_pci(E) virtio_ring(E) virtio(E) sg(E)
dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) scsi_dh_emc(E) scsi_dh_alua(E)
scsi_mod(E) autofs4(E)
Jan 03 11:35:19 linux-mainline kernel: CPU: 0 PID: 3349 Comm: ps
Tainted: G E 4.15.0-rc1-69-default #1
Jan 03 11:35:19 linux-mainline kernel: Hardware name: QEMU Standard PC
(i440FX + PIIX, 1996), BIOS
rel-1.9.1-0-gb3ef39f-prebuilt.qemu-project.org 04/01/2014
Jan 03 11:35:19 linux-mainline kernel: task: ffff880061efce80
task.stack: ffff880058bd0000
Jan 03 11:35:19 linux-mainline kernel: RIP:
0010:__mod_node_page_state+0x5/0x50
Jan 03 11:35:19 linux-mainline kernel: RSP: 0018:ffff880058bd7ce8
EFLAGS: 00010a07
Jan 03 11:35:19 linux-mainline kernel: RAX: 00000000000003ff RBX:
ffffea00011a3d80 RCX: 00000000011a3d80
Jan 03 11:35:19 linux-mainline kernel: RDX: ffffffffffffffff RSI:
000000000000000d RDI: 0000000000000000
Jan 03 11:35:19 linux-mainline kernel: RBP: ffffffffffffffff R08:
ffff88006378a630 R09: ffff880058bd7d98
Jan 03 11:35:19 linux-mainline kernel: R10: 00007f7f4d806280 R11:
0000000000000000 R12: ffffea00011a3d80
Jan 03 11:35:19 linux-mainline kernel: R13: 00007f7f4f318000 R14:
00007f7f4f31c000 R15: ffff880058bd7e18
Jan 03 11:35:19 linux-mainline kernel: FS: 0000000000000000(0000)
GS:ffff880066c00000(0000) knlGS:0000000000000000
Jan 03 11:35:19 linux-mainline kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
Jan 03 11:35:19 linux-mainline kernel: CR2: 0000000000029ec0 CR3:
0000000001c0d006 CR4: 00000000001606f0
Jan 03 11:35:19 linux-mainline kernel: Call Trace:
Jan 03 11:35:19 linux-mainline kernel: page_remove_rmap+0x11a/0x2b0
Jan 03 11:35:19 linux-mainline kernel: unmap_page_range+0x547/0xa30
Jan 03 11:35:19 linux-mainline kernel: unmap_vmas+0x42/0x90
Jan 03 11:35:19 linux-mainline kernel: exit_mmap+0x86/0x180
Jan 03 11:35:19 linux-mainline kernel: mmput+0x4a/0x110
Jan 03 11:35:19 linux-mainline kernel: do_exit+0x25d/0xae0
Jan 03 11:35:19 linux-mainline kernel: do_group_exit+0x39/0xa0
Jan 03 11:35:19 linux-mainline kernel: SyS_exit_group+0x10/0x10
Jan 03 11:35:19 linux-mainline kernel: entry_SYSCALL_64_fastpath+0x1a/0x7d
Jan 03 11:35:19 linux-mainline kernel: RIP: 0033:0x7f7f4eb8c338
Jan 03 11:35:19 linux-mainline kernel: RSP: 002b:00007ffca4400d48
EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
Jan 03 11:35:19 linux-mainline kernel: RAX: ffffffffffffffda RBX:
0000000000000000 RCX: 00007f7f4eb8c338
Jan 03 11:35:19 linux-mainline kernel: RDX: 0000000000000000 RSI:
000000000000003c RDI: 0000000000000000
Jan 03 11:35:19 linux-mainline kernel: RBP: 00007ffca4400d40 R08:
00000000000000e7 R09: fffffffffffffef8
Jan 03 11:35:19 linux-mainline kernel: R10: 00007f7f4d806280 R11:
0000000000000246 R12: 00007f7f4f756000
Jan 03 11:35:19 linux-mainline kernel: R13: 00007ffca4400cc8 R14:
00007f7f4f732b20 R15: 00007f7f4d5ebc70
Jan 03 11:35:19 linux-mainline kernel: Code: f7 d9 48 39 ca 7c 05 65 88
50 0f c3 f0 48 01 94 f7 00 05 00 00 f0 48 01 14 f5 c0 c4 c0 81 31 d2 eb
e5 0f 1f 40 00 0f 1f 44 00 00 <48> 8b 8f c0 9e 02 00 89 f6 48 8d 04 31
65 44 8a 40 01 4d 0f be
Jan 03 11:35:19 linux-mainline kernel: RIP:
__mod_node_page_state+0x5/0x50 RSP: ffff880058bd7ce8
Jan 03 11:35:19 linux-mainline kernel: CR2: 0000000000029ec0
Jan 03 11:35:19 linux-mainline kernel: ---[ end trace b5314eeef943a473 ]---
Jan 03 11:35:19 linux-mainline kernel: Fixing recursive fault but reboot
is needed!
Jan 03 11:35:19 linux-mainline kernel: XFS (vdd): Unmounting Filesystem
Occasionally mount process hangs forever.
linux-mainline:~ # cat /proc/19627/stack
[<ffffffff810a65f2>] io_schedule+0x12/0x40
[<ffffffff8119fbb7>] wait_on_page_bit+0xd7/0x100
[<ffffffff811b3713>] truncate_inode_pages_range+0x423/0x7c0
[<ffffffff81273768>] set_blocksize+0x98/0xb0
[<ffffffff81273798>] sb_set_blocksize+0x18/0x40
[<ffffffffa06a2e58>] xfs_fs_fill_super+0x1b8/0x590 [xfs]
[<ffffffff8123bd4d>] mount_bdev+0x17d/0x1b0
[<ffffffff8123c6d4>] mount_fs+0x34/0x150
[<ffffffff81259702>] vfs_kern_mount+0x62/0x110
[<ffffffff8125bd1a>] do_mount+0x1ca/0xc30
[<ffffffff8125ca6e>] SyS_mount+0x7e/0xd0
[<ffffffff8172fff3>] entry_SYSCALL_64_fastpath+0x1a/0x7d
[<ffffffffffffffff>] 0xffffffffffffffff
The test against bfq+ext4 have issues as well. However,
if I change the scheduler to mq-deadline or kyber, then
I can't see any calltrace, so I guess it is related with
bfq.
Thanks,
Guoqing
