From owner-svn-src-all@freebsd.org Wed Dec 13 13:38:19 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 B6EEAE9E60E; Wed, 13 Dec 2017 13:38:19 +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 802B170D66; Wed, 13 Dec 2017 13:38:19 +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 vBDDcHiP091866; Wed, 13 Dec 2017 05:38:17 -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 vBDDcHCM091865; Wed, 13 Dec 2017 05:38:17 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <201712131338.vBDDcHCM091865@pdx.rh.CN85.dnsmgr.net> Subject: Re: svn commit: r326809 - head/sys/dev/cardbus In-Reply-To: <20171213065443.GA31341@FreeBSD.org> To: Alexey Dokuchaev Date: Wed, 13 Dec 2017 05:38:17 -0800 (PST) CC: rgrimes@freebsd.org, 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-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 13:38:19 -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 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