Re: [PATCH] 9pfs: log warning if msize <= 8192

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Sep 02, 2020 at 03:39:34PM +0200, Greg Kurz wrote:
> 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.

To be clear, I'm not objecting to warning - just that the proposed warning
doesn't give any useful information about what is considered to be a
sensible alternative size, and nor does the commit message.

Just like to see the commit message provide the background info above,
and ideally have the warning message at least give the user a suggestion
that is in the sensible order of magnitude they should be looking at.

eg tell them to aim for 1 MB (or whatever value) as a starting point to
tuning.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|