Date: Sat, 04 Aug 2018 12:49:36 +0200 From: "Kristof Provost" <kp@FreeBSD.org> To: "Gleb Smirnoff" <glebius@freebsd.org> Cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r336221 - head/sys/net Message-ID: <25795E0A-A362-44B2-AC5A-573442FC256D@FreeBSD.org> In-Reply-To: <20180803230405.GI420@FreeBSD.org> References: <201807121635.w6CGZZAN046919@repo.freebsd.org> <20180803230405.GI420@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4 Aug 2018, at 1:04, Gleb Smirnoff wrote: > On Thu, Jul 12, 2018 at 04:35:35PM +0000, Kristof Provost wrote: > K> Author: kp > K> Date: Thu Jul 12 16:35:35 2018 > K> New Revision: 336221 > K> URL: https://svnweb.freebsd.org/changeset/base/336221 > K> > K> Log: > K> pf: Increate default state table size > K> > K> The typical system now has a lot more memory than when pf was = > new, and is also > K> expected to handle more connections. Increase the default size of = > the state > K> table. > K> Note that users can overrule this using 'set limit states' in = > pf.conf. > K> > K> From OpenBSD: > K> The year is 2018. > K> Mercury, Bowie, Cash, Motorola and DEC all left us. > K> Just pf still has a default state table limit of 10000. > K> Had! Now it's a tiny little bit more, 100k. > K> lead guitar: me > K> ok chorus: phessler theo claudio benno > K> background school girl laughing: bob > > For FreeBSD it would also make sense to bump hash sizes along with = > this change. > Yeah, Olivier did some benchmarking work around this: https://github.com/ocochard/netbenches/blob/master/Atom_C2758_8Cores-Chel= sio_T540-CR/pf-states_hashsize/results/fbsd12-head.r332390/README.md He found a roughly 10% increase in throughput by increasing the hash = size to 256K. I=E2=80=99ve been thinking about making the hash size dynamically configu= rable = (so we could calculate it based in the state limit, rather than expect = users to tune this manually), but that=E2=80=99s probably not going to ge= t = done any time soon. I=E2=80=99ll see about increasing the default (although perhaps not to 25= 6K, = because if my math is right that=E2=80=99s cost us ~20MB of memory) soon,= = because that=E2=80=99s mostly a quick win. Regards, Kristof From owner-svn-src-head@freebsd.org Sat Aug 4 10:58:46 2018 Return-Path: <owner-svn-src-head@freebsd.org> Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 182581066279; Sat, 4 Aug 2018 10:58:46 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr11p00im-asmtp004.me.com (mr11p00im-asmtp004.me.com [17.110.69.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A9E8C8F95F; Sat, 4 Aug 2018 10:58:45 +0000 (UTC) (envelope-from tsoome@me.com) Received: from process-dkim-sign-daemon.mr11p00im-asmtp004.me.com by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) id <0PCX00F00N46B100@mr11p00im-asmtp004.me.com>; Sat, 04 Aug 2018 10:58:38 +0000 (GMT) Received: from icloud.com ([127.0.0.1]) by mr11p00im-asmtp004.me.com (Oracle Communications Messaging Server 8.0.2.2.20180531 64bit (built May 31 2018)) with ESMTPSA id <0PCX003F1NTDXE30@mr11p00im-asmtp004.me.com>; Sat, 04 Aug 2018 10:58:30 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-08-04_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1011 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1808040123 Content-type: text/plain; charset=utf-8 MIME-version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Subject: Re: svn commit: r337271 - head/stand/i386/libi386 From: Toomas Soome <tsoome@me.com> In-reply-to: <87cc3ae5-cbef-0d04-071e-cb7f7a410ce8@delphij.net> Date: Sat, 04 Aug 2018 13:58:24 +0300 Cc: Cy Schubert <cy@FreeBSD.org>, src-committers <src-committers@freebsd.org>, svn-src-all@freebsd.org, svn-src-head@freebsd.org, tsoome@freebsd.org Content-transfer-encoding: quoted-printable Message-id: <7212F80A-9BA8-4D64-AB66-B8FA9F08409F@me.com> References: <201808031911.w73JB0WK025164@repo.freebsd.org> <87cc3ae5-cbef-0d04-071e-cb7f7a410ce8@delphij.net> To: d@delphij.net X-Mailer: Apple Mail (2.3445.9.1) X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: SVN commit messages for the src tree for head/-current <svn-src-head.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-head/>; List-Post: <mailto:svn-src-head@freebsd.org> List-Help: <mailto:svn-src-head-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/svn-src-head>, <mailto:svn-src-head-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 04 Aug 2018 10:58:46 -0000 > On 4 Aug 2018, at 11:54, Xin Li <delphij@delphij.net> wrote: >=20 > Hi, Cy, >=20 > On 8/3/18 12:11, Cy Schubert wrote: >> Author: cy >> Date: Fri Aug 3 19:11:00 2018 >> New Revision: 337271 >> URL: https://svnweb.freebsd.org/changeset/base/337271 >>=20 >> Log: >> Some drives report a geometry that is inconsisetent with the total >> number of sectors reported through the BIOS. Cylinders * heads * >> sectors may not necessarily be equal to the total number of sectors >> reported through int13h function 48h. >>=20 >> An example of this is when a Mediasonic HD3-U2B PATA to USB = enclosure >> with a 80 GB disk is attached. Loader hangs at line 506 of >> stand/i386/libi386/biosdisk.c while attempting to read sectors = beyond >> the end of the disk, sector 156906855. I discovered that the = Mediasonic >> enclosure was reporting the disk with 9767 cylinders, 255 heads, 63 >> sectors/track. That's 156906855 sectors. However camcontrol and >> Windows 10 both report report the disk having 156301488 sectors, not >> the calculated value. At line 280 biosdisk.c sets the sectors to the >> higher of either bd->bd_sectors or the total calculated at line 276 >> (156906855) instead of the lower and correct value of 156301488 = reported >> by int 13h 48h. >>=20 >> This was tested on all three of my Mediasonic HD3-U2B PATA to USB >> enclosures. >>=20 >> Instead of using the higher of bd_sectors (returned by int13h) or = the >> calculated value, this patch uses the lower and safer of the values. >>=20 >> Reviewed by: tsoome@ >> Differential Revision: https://reviews.freebsd.org/D16577 >>=20 >> Modified: >> head/stand/i386/libi386/biosdisk.c >>=20 >> Modified: head/stand/i386/libi386/biosdisk.c >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >> --- head/stand/i386/libi386/biosdisk.c Fri Aug 3 18:52:51 2018 = (r337270) >> +++ head/stand/i386/libi386/biosdisk.c Fri Aug 3 19:11:00 2018 = (r337271) >> @@ -275,7 +275,7 @@ bd_int13probe(struct bdinfo *bd) >>=20 >> total =3D (uint64_t)params.cylinders * >> params.heads * params.sectors_per_track; >> - if (bd->bd_sectors < total) >> + if (bd->bd_sectors > total) >> bd->bd_sectors =3D total; >>=20 >> ret =3D 1; >>=20 >=20 > This broke loader on my system, but I think your reasoning was valid = so > I took a deeper look and discovered that on my system, INT 13h, = function > 48h would give zeros in EDD parameters' CHS fields. With that, the > calculated CHS based total would be 0, and your change would cause > bd_sectors be zeroed. >=20 > Could you please let me know if https://reviews.freebsd.org/D16588 = makes > sense to you? (I'm not 100% certain if I have followed the code). It > allowed my Asrock C2750D4I based board to boot from ZFS. >=20 I have in mind something a bit different for some time, but haven=E2=80=99= t had chance to complete it because I have no =E2=80=9Cweird=E2=80=9D = systems to validate the idea:D I=E2=80=99ll try to get a bit of time and = post an phabricator soon. rgds, toomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?25795E0A-A362-44B2-AC5A-573442FC256D>