From owner-svn-src-all@freebsd.org Wed Dec 13 17:48:33 2017 Return-Path: Delivered-To: svn-src-all@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 8ED1CE81291; Wed, 13 Dec 2017 17:48:33 +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 0D6687ABB6; Wed, 13 Dec 2017 17:48:31 +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 vBDHmPsU027538 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Dec 2017 18:48:26 +0100 (CET) (envelope-from eugen@grosbein.net) X-Envelope-From: eugen@grosbein.net X-Envelope-To: rgrimes@freebsd.org Received: from [10.58.0.4] ([10.58.0.4]) by eg.sd.rdtc.ru (8.15.2/8.15.2) with ESMTPS id vBDHmL0S050482 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 14 Dec 2017 00:48:21 +0700 (+07) (envelope-from eugen@grosbein.net) Subject: Re: svn commit: r326809 - head/sys/dev/cardbus To: rgrimes@freebsd.org, Alexey Dokuchaev References: <201712131338.vBDDcHCM091865@pdx.rh.CN85.dnsmgr.net> Cc: Warner Losh , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org From: Eugene Grosbein Message-ID: <5A3167E1.2000201@grosbein.net> Date: Thu, 14 Dec 2017 00:48:17 +0700 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <201712131338.vBDDcHCM091865@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=2.2 required=5.0 tests=BAYES_00, LOCAL_FROM, RDNS_NONE autolearn=no autolearn_force=no version=3.4.1 X-Spam-Report: * -2.3 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 1.9 RDNS_NONE Delivered to internal network by a host with no rDNS * 2.6 LOCAL_FROM From my domains X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on hz.grosbein.net X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Dec 2017 17:48:33 -0000 13.12.2017 20:38, Rodney W. Grimes wrote: > That I can not answer, but I can say I have just found the problem > is NOT limited to i386, we can rather quickly blow up an amd64 system > running a dozen or so VM's. > > My bhyve host tossed a stack of these out last night: > vm_thread_new: kstack allocation failed > vm_thread_new: kstack allocation failed > vm_thread_new: kstack allocation failed > vm_thread_new: kstack allocation failed > vm_thread_new: kstack allocation failed > vm_thread_new: kstack allocation failed > vm_thread_new: kstack allocation failed > vm_thread_new: kstack allocation failed > vm_thread_new: kstack allocation failed > vm_thread_new: kstack allocation failed > > ZFS has been tuned to leave 1.2* my total VM allocations free space > of memory and I only had 10 out of 16 vm's running last night, so > there is tons of free memory. This is probalby KVA space starvation, > though I thought that was pretty much a non issue on amd64. > > I do think we should back out r326758 sooner rather than later, > and if it got MFC'd or flagged for MFC kill that right now. I don't understand why you want to backout that. It changed nothing for amd64. An i386 is still vulnerable to double faults just because of a network packet processing path can overflow kstack for the GENERIC kernel. If one has stripped-down kernel or just uses FreeBSD within safe environment preventing it from such packets, there is still loader.conf to change kstack_pages to any desired value for such special appliances that need lots of threads for i386. And I don't think someone should expect to run dozen of VMs within i386 kernel without some tuning. So please leave r326758 alone as it hardens FreeBSD in default setup and this is more important.