[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] 9pfs: log warning if msize <= 8192
From: |
Greg Kurz |
Subject: |
Re: [PATCH] 9pfs: log warning if msize <= 8192 |
Date: |
Wed, 2 Sep 2020 15:39:34 +0200 |
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
>
>
- [PATCH] 9pfs: log warning if msize <= 8192, Christian Schoenebeck, 2020/09/02
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Daniel P . Berrangé, 2020/09/02
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Christian Schoenebeck, 2020/09/02
- Re: [PATCH] 9pfs: log warning if msize <= 8192,
Greg Kurz <=
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Daniel P . Berrangé, 2020/09/02
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Christian Schoenebeck, 2020/09/02
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Daniel P . Berrangé, 2020/09/02
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Christian Schoenebeck, 2020/09/02
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Daniel P . Berrangé, 2020/09/02
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Greg Kurz, 2020/09/02
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Christian Schoenebeck, 2020/09/03
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Greg Kurz, 2020/09/03
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Christian Schoenebeck, 2020/09/03
- Re: [PATCH] 9pfs: log warning if msize <= 8192, Christian Schoenebeck, 2020/09/02