[v2,1/1] 9pfs: log warning if msize <= 8192

It is essential to choose a reasonable high value for 'msize' to avoid
severely degraded file I/O performance. This parameter can only be
chosen on client/guest side, and a Linux client defaults to an 'msize'
of only 8192 if the user did not explicitly specify a value for 'msize',
which results in very poor file I/O performance.

Unfortunately many users are not aware that they should specify an
appropriate value for 'msize' to avoid severe performance issues, so
log a performance warning (with a QEMU wiki link explaining this issue
in detail) on host side in that case to make it more clear.

Currently a client cannot automatically pick a reasonable value for
'msize', because a good value for 'msize' depends on the file I/O
potential of the underlying storage on host side, i.e. a feature
invisible to the client, and even then a user would still need to trade
off between performance profit and additional RAM costs, i.e. with
growing 'msize' (RAM occupation), performance still increases, but
performance delta will shrink continuously.

Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
---
 hw/9pfs/9p.c | 9 +++++++++
 1 file changed, 9 insertions(+)

On Thu, 3 Sep 2020 16:20:21 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> It is essential to choose a reasonable high value for 'msize' to avoid
> severely degraded file I/O performance. This parameter can only be
> chosen on client/guest side, and a Linux client defaults to an 'msize'
> of only 8192 if the user did not explicitly specify a value for 'msize',
> which results in very poor file I/O performance.
> 
> Unfortunately many users are not aware that they should specify an
> appropriate value for 'msize' to avoid severe performance issues, so
> log a performance warning (with a QEMU wiki link explaining this issue
> in detail) on host side in that case to make it more clear.
> 
> Currently a client cannot automatically pick a reasonable value for
> 'msize', because a good value for 'msize' depends on the file I/O
> potential of the underlying storage on host side, i.e. a feature
> invisible to the client, and even then a user would still need to trade
> off between performance profit and additional RAM costs, i.e. with
> growing 'msize' (RAM occupation), performance still increases, but
> performance delta will shrink continuously.
> 
> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> ---
>  hw/9pfs/9p.c | 9 +++++++++
>  1 file changed, 9 insertions(+)
> 
> diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> index 7bb994bbf2..99b6f24fd6 100644
> --- a/hw/9pfs/9p.c
> +++ b/hw/9pfs/9p.c
> @@ -1353,6 +1353,15 @@ static void coroutine_fn v9fs_version(void *opaque)
>          goto out;
>      }
>  
> +    /* 8192 is the default msize of Linux clients */
> +    if (s->msize <= 8192) {

I agree that an msize of 8192 suck from a performance standpoint but
I guess many users are msize agnostic, and they use the default value
without even knowing it. They might not even care for performance at
all, otherwise they'd likely ask google and they will eventually land
on:

https://wiki.qemu.org/Documentation/9psetup#Performance_Considerations

But with this patch, they will now get a warning each time they start
QEMU, maybe freak out and file reports in launchpad. So I suggest you
turn <= into < to avoid bothering these placid users with a warning.

Anyway, it's your choice :) so if you manage to get the #msize anchor to
work as expected:

Reviewed-by: Greg Kurz <groug@kaod.org>

> +        warn_report_once(
> +            "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."
> +        );
> +    }
> +
>  marshal:
>      err = pdu_marshal(pdu, offset, "ds", s->msize, &version);
>      if (err < 0) {

On Donnerstag, 3. September 2020 18:02:48 CEST Greg Kurz wrote:
> > diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
> > index 7bb994bbf2..99b6f24fd6 100644
> > --- a/hw/9pfs/9p.c
> > +++ b/hw/9pfs/9p.c
> > @@ -1353,6 +1353,15 @@ static void coroutine_fn v9fs_version(void *opaque)
> > 
> >          goto out;
> >      
> >      }
> > 
> > +    /* 8192 is the default msize of Linux clients */
> > +    if (s->msize <= 8192) {
> 
> I agree that an msize of 8192 suck from a performance standpoint but
> I guess many users are msize agnostic, and they use the default value
> without even knowing it. They might not even care for performance at
> all, otherwise they'd likely ask google and they will eventually land
> on:
> 
> https://wiki.qemu.org/Documentation/9psetup#Performance_Considerations
> 
> But with this patch, they will now get a warning each time they start
> QEMU, maybe freak out and file reports in launchpad. So I suggest you
> turn <= into < to avoid bothering these placid users with a warning.

Mmm, that's actually precisely my intended target group: people who have never 
been aware about the existence of 'msize' before.

I keep '<=' for now, I think the log message is already clear that you simply 
have to make it any 'msize' > 8192 and the warning is gone.

> Anyway, it's your choice :) so if you manage to get the #msize anchor to
> work as expected:

Works now (using raw html anchor instead):
https://wiki.qemu.org/Documentation/9psetup#msize

> Reviewed-by: Greg Kurz <groug@kaod.org>

Thanks Greg!

> > +        warn_report_once(
> > +            "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." +        );
> > +    }
> > +
> > 
> >  marshal:
> >      err = pdu_marshal(pdu, offset, "ds", s->msize, &version);
> >      if (err < 0) {

Best regards,
Christian Schoenebeck