Date: Tue, 12 Dec 2017 12:43:18 -0800 (PST) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Eugene Grosbein <eugen@grosbein.net> Cc: rgrimes@freebsd.org, Andriy Gapon <avg@freebsd.org>, Don Lewis <truckman@freebsd.org>, Alexey Dokuchaev <danfe@freebsd.org>, Konstantin Belousov <kostikbel@gmail.com>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Conrad Meyer <cem@freebsd.org> Subject: Re: svn commit: r326758 - in head/sys/i386: conf include Message-ID: <201712122043.vBCKhIsD088371@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <5A302DF7.1090706@grosbein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 13.12.2017 00:32, Rodney W. Grimes wrote: > > >> I am not sure if there are tools that can analyze stack requirements for > >> possible call chains rather than individual functions. > > > > Call graphs can be used to find deep chains. Combine the above > > with a call graph and we should be able to come up with some > > data. > > > > This also sounds like a good caniate for GSOC, creation > > of a call graph with static analysis of local variable size + > > call frame size requirements as a O(1) stack space estimator. > > "Longitude" of call chain greatly depends of run-time system configuration. > For example, application sendto() call can result in variable number > of system calls performing IPSEC transformations (ESP, AH, IPCOMP) > then custom PFIL processing then multiple NETGRAPH calls then complex > WiFi stack operations and each of such calls can result in kernel stack exhaustion. That was why I expressed it as an O(1) estimator. Attempting to do this more complex problem you describe would probably best be left to dtrace and some coverage metrics to make sure we hit most of the paths. At this time I don't think we need that. I think what you did with your very quick turn around of the simple static data is probably going to lead to rapid closure of the problem, or at least greatly reduce it. Or are you thinking we have something that is so deep even if it only uses 32 bytes of stack we are going to run ourselfs out of kstack under some work loads? I hope not. -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201712122043.vBCKhIsD088371>