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-Chelsio_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’ve been thinking about making the hash size dynamically configurable (so we could calculate it based in the state limit, rather than expect users to tune this manually), but that’s probably not going to get done any time soon. I’ll see about increasing the default (although perhaps not to 256K, because if my math is right that’s cost us ~20MB of memory) soon, because that’s 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 18-08-04_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policyfault score=0 spamscore=0 clxscore11 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: > > Hi, Cy, > > 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 >> >> 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. >> >> 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. >> >> This was tested on all three of my Mediasonic HD3-U2B PATA to USB >> enclosures. >> >> 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. >> >> Reviewed by: tsoome@ >> Differential Revision: https://reviews.freebsd.org/D16577 >> >> Modified: >> head/stand/i386/libi386/biosdisk.c >> >> Modified: head/stand/i386/libi386/biosdisk.c >> ============================================================================== >> --- 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) >> >> total = (uint64_t)params.cylinders * >> params.heads * params.sectors_per_track; >> - if (bd->bd_sectors < total) >> + if (bd->bd_sectors > total) >> bd->bd_sectors = total; >> >> ret = 1; >> > > 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. > > 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. > I have in mind something a bit different for some time, but haven’t had chance to complete it because I have no “weird” systems to validate the idea:D I’ll 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>