qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PULL v2 0/5] 9p queue (previous 2020-10-15)


From: Peter Maydell
Subject: Re: [PULL v2 0/5] 9p queue (previous 2020-10-15)
Date: Mon, 19 Oct 2020 11:22:47 +0100

On Mon, 19 Oct 2020 at 11:19, Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
>
> On Montag, 19. Oktober 2020 11:52:38 CEST Peter Maydell wrote:
> > This emits a lot of new warnings during 'make check':
> >
> > PASS 27 qtest-arm: qos-test
> > /arm/virt/virtio-mmio/virtio-bus/virtio-9p-device/virtio-9p/virtio-9p-tests/
> > local/config qemu-system-arm: warning: 9p: degraded performance: a
> > reasonable high msize should be chosen on client/guest side (chosen msize
> > is <= 8192). See https://wiki.qemu.org/Documentation/9psetup#msize for
> > details. PASS 28 qtest-arm: qos-test
> > /arm/virt/virtio-mmio/virtio-bus/virtio-9p-device/virtio-9p/virtio-9p-tests/
> > local/create_dir
> >
> > PASS 54 qtest-i386: qos-test
> > /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p
> > -tests/local/config qemu-system-i386: warning: 9p: degraded performance: a
> > reasonable high msize should be chosen on client/guest side (chosen msize
> > is <= 8192). See https://wiki.qemu.org/Documentation/9psetup#msize for
> > details. PASS 55 qtest-i386: qos-test
> > /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p
> > -tests/local/create_dir

> One warning per test suite run (i.e. per architecture due to
> warn_report_once()), yes. That performance warning is meant for end user
> installations to remind them setting some (reasonable high) value for 9p
> client parameter 'msize' on guest OS side. The warning triggers here because
> the 9p test cases intentionally run with a small 'msize' to guard edge cases.
>
> Would it be Ok for you to merge it with this performance warning for now? I
> can take care of silencing it before 5.2 release. It probably requires to
> introduce a new CL option to suppress performance warnings like these, or by
> finding a way to detect that we're currently just running qtests.

The usual approach is to suppress this kind of warning by guarding
it with if (qtest_enabled()) { ... }.

I'm generally reluctant to allow new warnings in, because then they
never go away and my scripts build up a long list of "ignore this
particular warning" exceptions.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]