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

[Christian Schoenebeck]

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.

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.

Best regards,
Christian Schoenebeck