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:=0A= >On Thu, Jan 9, 2020 at 1:55 PM Peter Jeremy <peter@rulingia.com<mailto:pet= er@rulingia.com>> wrote:=0A= >On 2020-Jan-09 16:45:19 +0100, Gary Jennejohn <gljennjohn@gmail.com<mailto= :gljennjohn@gmail.com>> wrote:=0A= >>On Thu, 9 Jan 2020 15:21:25 +0100 (CET)=0A= >>Wojciech Puchar <wojtek@puchar.net<mailto:wojtek@puchar.net>> wrote:=0A= >>> why FreeBSD default is so completely wrong for modern hardware?=0A= >>>=0A= >>> i think 4MB is OK for HDDs, more may be optimal for RAID5 arrays.=0A= >>=0A= >>POLA (principle of least amazement). I certainly don't need a MAXPHYS se= t=0A= >>to 4MB on my desktop machine.=0A= >=0A= >What are the downsides of running with MAXPHYS set to 4MB (or similar)?=0A= >=0A= >There's two issues. One, it makes every buf and bio 32 times larger.=0A= >Second, there's a lot of drivers that say their max I/O size is MAXPHYS wh= en 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 th= roughput).=0A= >=0A= >> Not everyone using FreeBSD is running=0A= >>servers with large amounts of memory and disk storage.=0A= >=0A= >Actually, I disagree with this statement. MAXPHYS on x86 was doubled from= =0A= >64KB to 128KB in r32724 - 22 years ago. A small, embedded system today ha= s=0A= >more RAM than a decent server had disk space then. I think we are well=0A= >overdue for an examination of many of the kernel parameters to take into= =0A= >account that a "typical" user machine today has 3 orders of magnitude more= =0A= >RAM, disk and performance than it had when most of the kernel parameters= =0A= >were last tweaked.=0A= >=0A= >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 bug= s to hunt...=0A= >=0A= >>It's a trivial change if it's beneficial in a certain use scenario. The= =0A= >>decision should be left up to the user.=0A= >=0A= >Actually, I suspect it would benefit most typical use cases - even an=0A= >average desktop machine does for more I/O than when the values were last= =0A= >set. Also, adjusting it isn't quite that easy - it's a compile-time=0A= >constant so a user has to build their own kernel and the Project is trying= =0A= >to get away from requiring users to build from source.=0A= >=0A= >And, before someone starts, the "it will hurt embedded systems" argument= =0A= >isn't a good reason for keeping the status quo for two main reasons:=0A= One thought here is to move them to machine/param.h, so they can be=0A= set to different defaults for different arches.=0A= =0A= rick=0A= [stuff snipped]=0A= =0A= Warner=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB14273F466964C217DB0C4816DD390>