From owner-svn-src-head@freebsd.org Thu Dec 14 12:27:08 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 6B10EEA26EB; Thu, 14 Dec 2017 12:27:08 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 11B6F1EA3; Thu, 14 Dec 2017 12:27:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id vBECQxSK002496 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 14 Dec 2017 14:27:02 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua vBECQxSK002496 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id vBECQxCB002495; Thu, 14 Dec 2017 14:26:59 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 14 Dec 2017 14:26:59 +0200 From: Konstantin Belousov To: Eugene Grosbein Cc: John Baldwin , Conrad Meyer , 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> 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> <5A3268E9.506@grosbein.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5A3268E9.506@grosbein.net> User-Agent: Mutt/1.9.1 (2017-09-22) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home 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:27:08 -0000 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.