Date: Thu, 9 Jan 2020 14:14:09 -0700 From: Warner Losh <imp@bsdimp.com> To: Peter Jeremy <peter@rulingia.com> Cc: Gary Jennejohn <gljennjohn@gmail.com>, Hans Petter Selasky <hps@selasky.org>, Rick Macklem <rmacklem@uoguelph.ca>, Conrad Meyer <cem@freebsd.org>, "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>, Wojciech Puchar <wojtek@puchar.net>, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: maximum MAXBSIZE Message-ID: <CANCZdfrY08MRGu3pXLksn%2Bn=CNGqbqkphvuzUFUpObg61X3fiA@mail.gmail.com> In-Reply-To: <20200109204943.GC25924@server.rulingia.com> References: <d79078c4-f1cb-93b9-ee6e-f689936c1e01@selasky.org> <YQBPR0101MB1427EEDE94AA6E34B49C3C09DD3F0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <20200108105136.0d54ebce@ernst.home> <alpine.BSF.2.20.2001081452360.44533@puchar.net> <20200108141810.GX23031@kib.kiev.ua> <CAG6CVpUrGyov12nQSKhofCPw5fAiXgDGChxf3-aFu1fKpirJTQ@mail.gmail.com> <alpine.BSF.2.20.2001091057420.96836@puchar.net> <CANCZdfokuE%2BKheFvSnx7M4he9Drx31xLj8o_GKUGJqKk32Oj7g@mail.gmail.com> <alpine.BSF.2.20.2001091520120.10661@puchar.net> <20200109164519.33fc7478@ernst.home> <20200109204943.GC25924@server.rulingia.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jan 9, 2020 at 1:55 PM Peter Jeremy <peter@rulingia.com> wrote: > On 2020-Jan-09 16:45:19 +0100, Gary Jennejohn <gljennjohn@gmail.com> > wrote: > >On Thu, 9 Jan 2020 15:21:25 +0100 (CET) > >Wojciech Puchar <wojtek@puchar.net> wrote: > >> why FreeBSD default is so completely wrong for modern hardware? > >> > >> i think 4MB is OK for HDDs, more may be optimal for RAID5 arrays. > > > >POLA (principle of least amazement). I certainly don't need a MAXPHYS set > >to 4MB on my desktop machine. > > What are the downsides of running with MAXPHYS set to 4MB (or similar)? > There's two issues. One, it makes every buf and bio 32 times larger. Second, there's a lot of drivers that say their max I/O size is MAXPHYS when really they mean max(128k,MAXPHYS). Newer hardware is better about it, but not perfect (I had to fix a NVMe bug because the format of SG lists we used is limited to 4k which means our NVMe driver can't do more than 1MB I/Os). DFLTPHYS also needs to be raised. There are (or were) some drivers in the tree that bogusly used DFLTPHYS as the maximum I/O, though I think I caught all of those. And once you bump MAXPHYS, there's other limits you'll run into with fast SSDs/NVMe drives (like runningbufs limiting write throughput). > > Not everyone using FreeBSD is running > >servers with large amounts of memory and disk storage. > > Actually, I disagree with this statement. MAXPHYS on x86 was doubled from > 64KB to 128KB in r32724 - 22 years ago. A small, embedded system today has > more RAM than a decent server had disk space then. I think we are well > overdue for an examination of many of the kernel parameters to take into > account that a "typical" user machine today has 3 orders of magnitude more > RAM, disk and performance than it had when most of the kernel parameters > were last tweaked. > Likely 1MB is the right place to have MAXPHYS for most people these days.... But there's a number of other parameters to tweak, and likely a few bugs to hunt... > >It's a trivial change if it's beneficial in a certain use scenario. The > >decision should be left up to the user. > > Actually, I suspect it would benefit most typical use cases - even an > average desktop machine does for more I/O than when the values were last > set. Also, adjusting it isn't quite that easy - it's a compile-time > constant so a user has to build their own kernel and the Project is trying > to get away from requiring users to build from source. > > And, before someone starts, the "it will hurt embedded systems" argument > isn't a good reason for keeping the status quo for two main reasons: > > 1) As I mentioned above, an embedded system today is larger than a decent > server was in 1998. > > 2) People running FreeBSD on embedded systems are going to want to build > from source to cater for their systems' idiosyncracies and needs, so they > can easily tune kernel parameters as needed. > I think we should look at changing these parameters, but some care is needed because there's often interrelated values that aren't obvious to someone new to this tuning. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrY08MRGu3pXLksn%2Bn=CNGqbqkphvuzUFUpObg61X3fiA>