netdev - Re: [PATCH v4 00/12] remove msize limit in virtio transport

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 22 Jan 2022 14:34:24 +0100
From:   Christian Schoenebeck <linux_oss@...debyte.com>
To:     Nikolay Kichukov <nikolay@...um.net>
Cc:     v9fs-developer@...ts.sourceforge.net, netdev@...r.kernel.org,
        Dominique Martinet <asmadeus@...ewreck.org>,
        Eric Van Hensbergen <ericvh@...il.com>,
        Latchesar Ionkov <lucho@...kov.net>,
        Greg Kurz <groug@...d.org>, Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH v4 00/12] remove msize limit in virtio transport

On Donnerstag, 20. Januar 2022 23:43:46 CET Nikolay Kichukov wrote:
> Thanks for the patches. I've applied them on top of 5.16.2 kernel and it
> works for msize=1048576. Performance-wise, same throughput as the
> previous patches, basically limiting factor is the backend block
> storage.

Depends on how you were testing exactly. I assume you just booted a guest and 
then mounted a humble 9p directory in guest to perform some isolated I/O 
throughput tests on a single file. In this test scenario yes, you would not 
see much of a difference between v3 vs. v4 of this series.

However in my tests I went much further than that by running an entire guest 
on top of 9p as its root filesystem:
https://wiki.qemu.org/Documentation/9p_root_fs
With this 9p rootfs setup you get a completely different picture. For instance 
you'll notice with v3 that guest boot time *increases* with rising msize, 
whereas with v4 it shrinks. And also when you benchmark throughput on a file 
in this 9p rootfs setup with v3 you get worse results than with v4, sometimes 
with v3 even worse than without patches at all. With v4 applied though it 
clearly outperforms any other kernel version in all aspects.

I highly recommend this 9p rootfs setup as a heterogenous 9p test environment, 
as it is a very good real world test scenario for all kinds of aspects.

> However, when I mount with msize=4194304, the system locks up upon first
> try to traverse the directory structure, ie 'ls'. Only solution is to
> 'poweroff' the guest. Nothing in the logs.

I've described this in detail in the cover letter under "KNOWN LIMITATIONS" 
already. Use max. msize 4186112.

> Qemu 6.0.0 on the host has the following patches:
> 
> 01-fix-wrong-io-block-size-Rgetattr.patch
> 02-dedupe-iounit-code.patch
> 03-9pfs-simplify-blksize_to_iounit.patch

I recommend just using QEMU 6.2. It is not worth to patch that old QEMU 
version. E.g. you would have a lousy readdir performance with that QEMU 
version and what not.

You don't need to install QEMU. You can directly run it from the build 
directory.

> The kernel patches were applied on the guest kernel only.
> 
> I've generated them with the following command:
> git diff
> 783ba37c1566dd715b9a67d437efa3b77e3cd1a7^..8c305df4646b65218978fc6474aa0f5f
> 29b216a0 > /tmp/kernel-5.16-9p-virtio-drop-msize-cap.patch
> 
> The host runs 5.15.4 kernel.

Host kernel version currently does not matter for this series.

Best regards,
Christian Schoenebeck