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]

Message-ID: <5111aae45d30df13e42073b0af4f16caf9bc79f0.camel@oldum.net>
Date:   Mon, 24 Jan 2022 11:21:08 +0100
From:   Nikolay Kichukov <nikolay@...um.net>
To:     Christian Schoenebeck <linux_oss@...debyte.com>
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

Thanks Christian,
It works, sorry for overlooking the 'known limitations' in the first
place. When do we expect these patches to be merged upstream?

Cheers,
-N


On Sat, 2022-01-22 at 14:34 +0100, Christian Schoenebeck wrote:
> 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^..8c305df4646b65218978fc647
> > 4aa0f5f
> > 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
> 
>