From owner-freebsd-hackers@freebsd.org Thu Jan 9 20:55:46 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 496751F8BD4 for ; Thu, 9 Jan 2020 20:55:46 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vtr.rulingia.com (vtr.rulingia.com [IPv6:2001:19f0:5801:ebe:5400:1ff:fe53:30fd]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vtr.rulingia.com", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47tyt70SY3z3Bnm for ; Thu, 9 Jan 2020 20:50:06 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from server.rulingia.com (ppp239-208.static.internode.on.net [59.167.239.208]) by vtr.rulingia.com (8.15.2/8.15.2) with ESMTPS id 009Knnen042925 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 10 Jan 2020 07:49:55 +1100 (AEDT) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.15.2/8.15.2) with ESMTPS id 009KnhDl063734 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jan 2020 07:49:44 +1100 (AEDT) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.15.2/8.15.2/Submit) id 009KnhCT063733; Fri, 10 Jan 2020 07:49:43 +1100 (AEDT) (envelope-from peter) Date: Fri, 10 Jan 2020 07:49:43 +1100 From: Peter Jeremy To: Gary Jennejohn Cc: Wojciech Puchar , Hans Petter Selasky , Rick Macklem , Conrad Meyer , "freebsd-hackers@freebsd.org" , Konstantin Belousov Subject: Re: maximum MAXBSIZE Message-ID: <20200109204943.GC25924@server.rulingia.com> References: <20200108105136.0d54ebce@ernst.home> <20200108141810.GX23031@kib.kiev.ua> <20200109164519.33fc7478@ernst.home> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA" Content-Disposition: inline In-Reply-To: <20200109164519.33fc7478@ernst.home> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.12.2 (2019-09-21) X-Rspamd-Queue-Id: 47tyt70SY3z3Bnm X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of peter@rulingia.com designates 2001:19f0:5801:ebe:5400:1ff:fe53:30fd as permitted sender) smtp.mailfrom=peter@rulingia.com X-Spamd-Result: default: False [-7.61 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[rulingia.com]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:20473, ipnet:2001:19f0:5800::/38, country:US]; RCVD_TLS_ALL(0.00)[]; IP_SCORE(-3.21)[ip: (-9.68), ipnet: 2001:19f0:5800::/38(-4.84), asn: 20473(-1.47), country: US(-0.05)] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jan 2020 20:55:46 -0000 --W/nzBZO5zC0uMSeA Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2020-Jan-09 16:45:19 +0100, Gary Jennejohn wrote: >On Thu, 9 Jan 2020 15:21:25 +0100 (CET) >Wojciech Puchar wrote: >> why FreeBSD default is so completely wrong for modern hardware? >>=20 >> 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)? > 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. >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 =66rom source to cater for their systems' idiosyncracies and needs, so they can easily tune kernel parameters as needed. --=20 Peter Jeremy --W/nzBZO5zC0uMSeA Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAl4XkeJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzQ2Mw/+M5p4TwHbNfZ3B2jQnmuzeqfLMRAWl4AY7t9QPuVr0o2nxSTFW4apdipM 9U0sEX5YTbCp9iqU7mDzv69zHQDG/TURsKKkZtLV91c6+6a6u0b8OsN7+3UYCd3b 8fhWsKVw+sFJ926RsZu3GDQzypk5ozv+2i/E/yZm1gjF7LjGDIviRopVDLvOKpBp wB2Yk5olxqTKWR2/Xjrgrmiws1tsfLGpgD/k7PxlfuwNBJUDgtbstEGfabRXBHeh H+IS3jq/f2JM3/cG+8eol2wUazK5PD5mOlgI5HW5p0iEH3m+jHEiadGr0FaeCJ/Z n1gkjGCYJdixbwYt+ceNTWPFW3d8Tjtml7+GNj76cwovcQWvFvlwxiWwQUqczDg/ NuDYPfqZj3kifdxku2VQLPj7W2BOmXrwaMnSQwSPHwNLBKvOmGJ50ERWke+9GWTU uwmsgVo3CEymYURPBm6HTWDldXaG3FJNm1MwUxMoLQQAZmHScYC7dHMV6RA2tM8U r+cvF4Ml3UfZaW63NLausNfrPKJz4PyTvCXlX+ySwWNVN0KuieSb/gn12N6ZuiOH POub0FkzrdSd3iiMqQiAEvTwwUUPz8RL+xprEBJLSSrNy2hSGpHT1nxRzP5c25yt fYFjYzE86s41RFjFcvNEUAb+hoFXS3j24HAm+OVGfL0gxn0I6TU= =rvTE -----END PGP SIGNATURE----- --W/nzBZO5zC0uMSeA--