From owner-svn-src-head@freebsd.org Thu Dec 14 12:05:15 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 22B8EEA1FBC; Thu, 14 Dec 2017 12:05:15 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from hz.grosbein.net (hz.grosbein.net [78.47.246.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hz.grosbein.net", Issuer "hz.grosbein.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 907371369; Thu, 14 Dec 2017 12:05:14 +0000 (UTC) (envelope-from eugen@grosbein.net) Received: from eg.sd.rdtc.ru (root@eg.sd.rdtc.ru [62.231.161.221] (may be forged)) by hz.grosbein.net (8.15.2/8.15.2) with ESMTPS id vBEC51PV035834 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Dec 2017 13:05:02 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: kostikbel@gmail.com Received: from eg.sd.rdtc.ru (eugen@localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTP id vBEC4vFv052267; Thu, 14 Dec 2017 19:04:57 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: svn commit: r326758 - in head/sys/i386: conf include To: Konstantin Belousov 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> <5A3261BD.5050404@grosbein.net> <20171214115149.GC2272@kib.kiev.ua> Cc: John Baldwin , Conrad Meyer , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org From: Eugene Grosbein X-Enigmail-Draft-Status: N1110 Message-ID: <5A3268E9.506@grosbein.net> Date: Thu, 14 Dec 2017 19:04:57 +0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <20171214115149.GC2272@kib.kiev.ua> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE, T_DATE_IN_FUTURE_Q_PLUS autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * 0.0 T_DATE_IN_FUTURE_Q_PLUS Date: is over 4 months after Received: date * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 2.6 LOCAL_FROM From my domains * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-Spam-Level: ** X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 12:05:15 -0000 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. Perhaps, it's time to make KVA_PAGES loader tunnable too? 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)?