From owner-svn-src-head@freebsd.org Wed Dec 13 13:44:36 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 579A5E9E92E; Wed, 13 Dec 2017 13:44:36 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1E85F711EC; Wed, 13 Dec 2017 13:44:35 +0000 (UTC) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBDDiYhj091914; Wed, 13 Dec 2017 05:44:34 -0800 (PST) (envelope-from freebsd@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBDDiYOp091913; Wed, 13 Dec 2017 05:44:34 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201712131344.vBDDiYOp091913@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r326809 - head/sys/dev/cardbus In-Reply-To: <201712131338.vBDDcHCM091865@pdx.rh.CN85.dnsmgr.net> To: rgrimes@freebsd.org Date: Wed, 13 Dec 2017 05:44:34 -0800 (PST) CC: Alexey Dokuchaev , Warner Losh , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Reply-To: rgrimes@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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: Wed, 13 Dec 2017 13:44:36 -0000 > > On Tue, Dec 12, 2017 at 12:39:38PM -0800, Rodney W. Grimes wrote: > > > > New Revision: 326809 > > > > URL: https://svnweb.freebsd.org/changeset/base/326809 > > > > > > > > Log: > > > > 1k objects on the stack are a bad idea. While it's likely safe in this > > > > context, it's also safe to allocate the memory and free it instead. > > > > > > > > Noticed by: Eugene Grosbein's script > > > > > > YEA!!! One down, 20 to go and then see how the kstack issue does? > > > > > > And thank you for quickly fixing this. > > > > It's very promising to see debloat-type of work having started. On the > > related note, what is current consensus with r326758, is it going to be > > backed out and stack issues investigated and fixed? I am worried since > > kib@ had mentioned that he's "almost sure that [32-bit x86 workstation] > > users would get troubles now" [*] and I'm one of them. > > 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 Ok, ignore this, the console was connected to a vm, these messages are infact from a vm running i386 11.1, just upgraded from 11.0 to 11.1 so even between that step there is a regression as I did not have these on the 11.0 system. > 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. > > A regression test would also be nice that can push the system > close to what the usable limit is, and that test should be run > in a CI situtaion to make sure we keep it running. This is a > non trivial to do though as there are many work load patterns > that can push the kernel towards stack space limits. > > -- > Rod Grimes rgrimes@freebsd.org -- Rod Grimes rgrimes@freebsd.org