Date: Tue, 12 Dec 2017 09:01:05 -0800 (PST) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Eugene Grosbein <eugen@grosbein.net> Cc: rgrimes@freebsd.org, Don Lewis <truckman@freebsd.org>, 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: <201712121701.vBCH153d087153@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <5A2FFFFB.4030501@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[ Charset windows-1252 unsupported, converting... ] > 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" I didnt mean to make it sound like it was IPSEC only, I simply meant to say that in general we have a kstack use regression that appears to have started after 10.x. I hope this clarifies my point. > 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. We should probably start looking for those, something someone who is offerring help but doesnt know what they might be good at, but can read C code. They could be utililized t simply scan through the code looking for this type of thing and bring it to the attention of a area of expertise commiter. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201712121701.vBCH153d087153>