qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Greg Kurz <groug@kaod.org>
To: Christian Schoenebeck <qemu_oss@crudebyte.com>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [PATCH] 9pfs: log warning if msize <= 8192
Date: Wed, 2 Sep 2020 15:39:34 +0200	[thread overview]
Message-ID: <20200902153934.5a2d7f86@bahia.lan> (raw)
In-Reply-To: <399764553.t4N7NBxW8t@silver>

On Wed, 02 Sep 2020 14:52:33 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Mittwoch, 2. September 2020 14:25:47 CEST Daniel P. Berrangé wrote:
> > On Wed, Sep 02, 2020 at 01:22:49PM +0200, Christian Schoenebeck wrote:
> > > It is essential to choose a reasonable high value for 'msize' to avoid
> > > severe degraded file I/O performance. This parameter has to 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'.
> > > 
> > > 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 on host side in that case to make it more
> > > clear.
> > 
> > What is a more reasonable "msize" value to pick instead of 8k ?
> > ie at what msize is I/O not several degraded ?
> 
> A good value depends on the file I/O potential of the underlying storage on 
> host side, and then you still would 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.
> 
> So in practice you might e.g. choose anything between 10MiB ... >100MiB for a 
> SATA spindle disk storage, and a much higher value for anything PCIe based 
> flash storage. So a user probably should benchmark and decide what's 
> reasonable for the intended use case.
> 
> > If there a reason that Linux can't pick a better default ?
> 
> I was not involved when that default value was picked on Linux side, so I 
> don't know why exactly this value (8192) had been chosen as default 'msize' 
> years ago.
> 

The original size back in 2005 was 9000:

[greg@bahia kernel-linus]$ git show 9e82cf6a802a7 | grep 9000
+	v9ses->maxdata = 9000;
+	if (v9ses->maxdata != 9000)

which was later converted to 8192.

I couldn't find any hint on why such a small size was chosen.

Maybe you can try to contact 9pfs father ?

Eric Van Hensbergen <ericvh@gmail.com>

> It certainly (sh/c)ould be higher, as it is already close to the theoreticaly 
> minimum msize of 4096. However how should a Linux guest automatically pick a 
> reasonable msize if it does not have any knowlege of host's storage features?
> 
> But even if this will be addressed on Linux kernel side, I still think users 
> of old kernels should be made aware of this issue, as it is not obvious to the 
> user.
> 

I tend to agree. Until linux decides of a better default, we should only
warn the user if they decide to go below the current one.

Cheers,

--
Greg

> Best regards,
> Christian Schoenebeck
> 
> 



  reply	other threads:[~2020-09-02 13:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-02 11:22 [PATCH] 9pfs: log warning if msize <= 8192 Christian Schoenebeck
2020-09-02 12:25 ` Daniel P. Berrangé
2020-09-02 12:52   ` Christian Schoenebeck
2020-09-02 13:39     ` Greg Kurz [this message]
2020-09-02 13:45       ` Daniel P. Berrangé
2020-09-02 14:08         ` Christian Schoenebeck
2020-09-02 14:10           ` Daniel P. Berrangé
2020-09-02 16:03             ` Christian Schoenebeck
2020-09-02 16:08               ` Daniel P. Berrangé
2020-09-02 16:54               ` Greg Kurz
2020-09-03  8:20                 ` Christian Schoenebeck
2020-09-03  9:35                   ` Greg Kurz
2020-09-03 10:57                     ` Christian Schoenebeck
2020-09-02 13:58       ` Christian Schoenebeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200902153934.5a2d7f86@bahia.lan \
    --to=groug@kaod.org \
    --cc=berrange@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu_oss@crudebyte.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).