Date: Thu, 9 Jan 2020 22:37:39 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Warner Losh <imp@bsdimp.com>, Peter Jeremy <peter@rulingia.com> Cc: Gary Jennejohn <gljennjohn@gmail.com>, Hans Petter Selasky <hps@selasky.org>, 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: <YQBPR0101MB14273F466964C217DB0C4816DD390@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CANCZdfrY08MRGu3pXLksn%2Bn=CNGqbqkphvuzUFUpObg61X3fiA@mail.gmail.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>, <CANCZdfrY08MRGu3pXLksn%2Bn=CNGqbqkphvuzUFUpObg61X3fiA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Warner Losh wrote: >On Thu, Jan 9, 2020 at 1:55 PM Peter Jeremy <peter@rulingia.com<mailto:peter@rulingia.com>> wrote: >On 2020-Jan-09 16:45:19 +0100, Gary Jennejohn <gljennjohn@gmail.com<mailto:gljennjohn@gmail.com>> wrote: >>On Thu, 9 Jan 2020 15:21:25 +0100 (CET) >>Wojciech Puchar <wojtek@puchar.net<mailto: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: One thought here is to move them to machine/param.h, so they can be set to different defaults for different arches. rick [stuff snipped] Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB14273F466964C217DB0C4816DD390>