[ 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 rgri...@freebsd.org _______________________________________________ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
