| Message ID | e6fc84845c95816ad5baecb0abd6bfefdcf7ec9f.1599144062.git.qemu_oss@crudebyte.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | 9pfs: log warning if msize <= 8192 | expand |
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
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) { + 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) {
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(+)