for-next: issues when running as qemu root in various caching modes

[ericvh]

On Tuesday, January 24, 2023 3:38:23 AM CET Eric Van Hensbergen wrote:

This is the third version of a patch series which adds a number
of features to improve read/write performance in the 9p filesystem.
Mostly it focuses on fixing caching to help utilize the recently
increased MSIZE limits and also fixes some problematic behavior
within the writeback code.

All together, these show roughly 10x speed increases on simple
file transfers. Future patch sets will improve cache consistency
and directory caching.

These patches are also available on github:
https://github.com/v9fs/linux/tree/ericvh/for-next
and on kernel.org:
https://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs.git

Tested against qemu, cpu, and diod with fsx, dbench, and some
simple benchmarks.

Looks like this needs more work.

I only had a glimpse on your patches yet, but made some tests by doing
compilations on guest on top of a 9p root fs [1], msize=500k. Under that
scenario:

• loose: this is suprisingly the only mode where I can see some performance
  increase, over "loose" on master it compiled ~5% faster, but I also got some
  misbehaviours on guest.

• writeahead: no performance results, as compilation already aborts when
  trying to detect a compiler. I had to restore a previous snapshot to repair
  things after this test.

• readahead: significant performance drop. In comparison to "loose" on master
  compilation takes 6 times longer with "readahead". There are some severe
  misbehaviours on guest as well, and after boot I get this warning:

[ 5.782846] folio expected an open fid inode->i_private=0000000000000000
[ 5.786641] WARNING: CPU: 0 PID: 321 at fs/9p/vfs_addr.c:174 v9fs_vfs_write_folio_locked (fs/9p/vfs_addr.c:174 (discriminator 3)) 9p
[ 5.792496] Modules linked in: ppdev(E) bochs(E) sg(E) drm_vram_helper(E) joydev(E) evdev(E) drm_kms_helper(E) serio_raw(E) drm_ttm_helper(E) pcsp)
[ 5.816806] CPU: 0 PID: 321 Comm: chown Tainted: G E 6.2.0-rc6+ torvalds#61
[ 5.821694] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.1-0-g3208b098f51a-prebuilt.qemu.org 04/01/2014
[ 5.827362] RIP: 0010:v9fs_vfs_write_folio_locked (fs/9p/vfs_addr.c:174 (discriminator 3)) 9p

Code starting with the faulting instruction

    ...

[ 5.835360] RSP: 0018:ffffc900007d3a38 EFLAGS: 00010282
[ 5.836982] RAX: 0000000000000000 RBX: ffff888106c86680 RCX: 0000000000000000
[ 5.838877] RDX: 0000000000000001 RSI: ffffffff821eb1e6 RDI: 00000000ffffffff
[ 5.841179] RBP: ffffea0004279300 R08: 0000000000000000 R09: 00000000ffffefff
[ 5.843039] R10: ffffc900007d38e8 R11: ffffffff824bede8 R12: 0000000000000000
[ 5.844850] R13: 00000000ffffffea R14: 0000000000000014 R15: 0000000000000014
[ 5.846366] FS: 00007fd0fc4a0580(0000) GS:ffff88842fc00000(0000) knlGS:0000000000000000
[ 5.848250] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 5.849386] CR2: 00007fd0fc38f4f0 CR3: 0000000100302000 CR4: 00000000000006f0
[ 5.850824] Call Trace:
[ 5.851622]
[ 5.852052] v9fs_vfs_writepage (fs/9p/vfs_addr.c:207) 9p
[ 5.852841] __writepage (mm/page-writeback.c:2537)
[ 5.853438] write_cache_pages (mm/page-writeback.c:2473)
[ 5.854205] ? __pfx___writepage (mm/page-writeback.c:2535)
[ 5.855309] ? delete_node (lib/radix-tree.c:575)
[ 5.856122] ? radix_tree_delete_item (lib/radix-tree.c:1432)
[ 5.857101] do_writepages (mm/page-writeback.c:2564 mm/page-writeback.c:2552 mm/page-writeback.c:2583)
[ 5.857954] ? radix_tree_delete_item (lib/radix-tree.c:1432)
[ 5.859103] filemap_fdatawrite_wbc (mm/filemap.c:389 mm/filemap.c:378)
[ 5.860043] __filemap_fdatawrite_range (mm/filemap.c:422)
[ 5.861050] filemap_write_and_wait_range (mm/filemap.c:682 mm/filemap.c:665)
[ 5.862132] v9fs_vfs_setattr_dotl (./include/linux/pagemap.h:60 fs/9p/vfs_inode_dotl.c:583) 9p
[ 5.863312] notify_change (fs/attr.c:486)
[ 5.864043] ? chown_common (fs/open.c:736)
[ 5.864793] chown_common (fs/open.c:736)
[ 5.865538] ? preempt_count_add (./include/linux/ftrace.h:977 kernel/sched/core.c:5737 kernel/sched/core.c:5734 kernel/sched/core.c:5762)
[ 5.866420] do_fchownat (fs/open.c:768)
[ 5.867419] __x64_sys_fchownat (fs/open.c:782 fs/open.c:779 fs/open.c:779)
[ 5.868319] do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)
[ 5.869116] entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)
[ 5.871008] RIP: 0033:0x7fd0fc3b7b9a

Best regards,
Christian Schoenebeck

[1] https://wiki.qemu.org/Documentation/9p_root_fs

[ericvh]

fixed everything except for fscache

[ericvh]

should now be fixed for fscache in for-next