maximum MAXBSIZE

[Rick Macklem]

Warner Losh wrote:
>On Thu, Jan 9, 2020 at 1:55 PM Peter Jeremy <peter at rulingia.com<mailto:peter at rulingia.com>> wrote:
>On 2020-Jan-09 16:45:19 +0100, Gary Jennejohn <gljennjohn at gmail.com<mailto:gljennjohn at gmail.com>> wrote:
>>On Thu, 9 Jan 2020 15:21:25 +0100 (CET)
>>Wojciech Puchar <wojtek at puchar.net<mailto:wojtek at 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