Date: Tue, 12 Dec 2017 23:12:43 +0700 From: Eugene Grosbein <eugen@grosbein.net> To: rgrimes@FreeBSD.org, Don Lewis <truckman@FreeBSD.org> Cc: Alexey Dokuchaev <danfe@FreeBSD.org>, Konstantin Belousov <kostikbel@gmail.com>, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Conrad Meyer <cem@FreeBSD.org> Subject: Re: svn commit: r326758 - in head/sys/i386: conf include Message-ID: <5A2FFFFB.4030501@grosbein.net> In-Reply-To: <201712121530.vBCFUU2G086785@pdx.rh.CN85.dnsmgr.net> References: <201712121530.vBCFUU2G086785@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
12.12.2017 22:30, Rodney W. Grimes: >>> Now I run FreeBSD 11/i386 as my home router with IPSEC and torrent >>> client, and I run several virtualized routers with IPSEC tunnels, >>> jabber and mail server, squid and ZFS for src/obj/ports compression >>> and they all easily crash unless kern.kstack_pages raised upto 4. Same >>> for some other my i386 installations having IPSEC tunnels. >> >> IPSEC definitely used to wwith with kstack_pages=2 since I ran that way >> for a number of years. I haven't used IPSEC since I upgraded from >> FreeBSD 8.x to 10.x a while back, so it could be broken now. > > I think this comes as a regression in 10.x or perhaps later. So that > atleast narrows down what has triggered the need for more kernel stack > space. Once again, that's not about IPSEC only that, indeed, had this kind of "regression" with overhaul of its code between 11.0 and 11.1 releases with r315514. It was already polished in stable/11 with later r319118 plus there is https://reviews.freebsd.org/D9721 that introduces new sysctl net.inet.ipsec.use_netisr=1 to convert long path of direct function calls requiring large stack to queuing of outgoing to-be-encrypted traffic using NETISR at cost of some performance penalty when enabled. But many other parts of kernel think it's OK to allocate big arrays or structures on stack.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5A2FFFFB.4030501>