Hi Eric, do you remember any specific reason why the default 'msize' for the Linux kernel's 9P client was chosen such low as 8 kiB? (see QEMU discussion below).
Best regards, Christian Schoenebeck On Mittwoch, 2. September 2020 15:39:34 CEST Greg Kurz wrote: > On Wed, 02 Sep 2020 14:52:33 +0200 > > Christian Schoenebeck <qemu_...@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 <eri...@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
