Date: Thu, 14 Dec 2017 14:26:59 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Eugene Grosbein <eugen@grosbein.net> Cc: John Baldwin <jhb@FreeBSD.org>, Conrad Meyer <cem@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r326758 - in head/sys/i386: conf include Message-ID: <20171214122659.GF2272@kib.kiev.ua> In-Reply-To: <5A3268E9.506@grosbein.net> References: <201712110432.vBB4WbnE021090@repo.freebsd.org> <20171211091943.GF2272@kib.kiev.ua> <5A2E5D44.9030904@grosbein.net> <4a9c76c9-8063-9420-b198-14487b089840@FreeBSD.org> <5A30378A.3040609@grosbein.net> <e2c426c3-41ed-2dd8-c5d4-15c60d8f7303@FreeBSD.org> <5A3261BD.5050404@grosbein.net> <20171214115149.GC2272@kib.kiev.ua> <5A3268E9.506@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 14, 2017 at 07:04:57PM +0700, Eugene Grosbein wrote: > On 14.12.2017 18:51, Konstantin Belousov wrote: > > >> I think thats's NFS code who is guilty. You can see example of amd64 (sic!) kstack exhaustion > >> due to 40+ frames deep call chain here: > >> > >> https://lists.freebsd.org/pipermail/freebsd-stable/2017-July/087429.html > > > > Yes, NFS crosses network/VFS and often VM boundaries, so each subsystem > > adds its usual stack use footprint to the overall picture. NFS reconnect > > is especially hard in this regard, and in case the direct dispatch is > > triggered (in this case over loopback) machine has no chance. > > > > The backtrace you cited just reinforces the point that the i386 commit > > is wrong. It breaks the workload we aims as the main FreeBSD target, > > which is generic-purpose Unix workstation or server. The commit tries > > to make defaults fit for specific appliance load of router with IPSEC > > or ZFS on i386, which require extensive tuning on i386 anyway. Worse, > > as you prove above, the commit in fact does not fix the issues, it only > > papers over them and move easily triggered faults from one configuration > > to another. > > Modern FreeBSD usage as workstation/server should not exclude IPv6, SCTP, WiFi, > and even ZFS nor IPSEC for i386. GENERIC kernel should not panic due to low volume > network activity with default settings. And two ponies should be given to everybody who wishes for them. > > Perhaps, it's time to make KVA_PAGES loader tunnable too? Sure, make it the tunable. Just to make you know in advance, this is quite delicate. > And/or increase its default for i386 upto some value corresponding to stable management > of kern.threads.max_threads_per_proc=1500 (by default) with kstack_pages=4 ? > > Maybe, KVA_PAGES=384 (1.5GB for 1500 threads)? Sigh. This would make i386 even less usable for everybody, perhaps except you. Because default 3G of UVA is too small for some common tasks (thanks clang, but also e.g. pypy), and you reduce the user address space even more.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171214122659.GF2272>