Date: Sun, 30 Sep 2007 21:22:06 -0700 From: Julian Elischer <julian@elischer.org> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: Kernel thread stack usage Message-ID: <470075EE.1030104@elischer.org> In-Reply-To: <46FFD850.1040508@FreeBSD.org> References: <46FFD850.1040508@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Motin wrote: > Hi. > > As known in netgraph susbystem information passing from one node to > another by direct function calls without queueing. It gives performance > bonuses, but it also gives permanent stack overflow risk on complicated > graphs. Netgraph is still have a queues and able to use them when asked, > but now queueing is a flag which should be controlled by sending node. I > think it would be good to implement some algorithm which could monitor > stack usage on each call and enforce queueing when stack usage become > critical. > > The question is: is there correct way to somehow get current kernel > thread stack usage or just a stack base address? > I've thought about this quite a bit over the years. On possibility is a stack usage meter (which once did work out) and another is to have a 'hop count (or recursion count) added to the arguments passed around with the data. The nodes would have to cooperate with this scheme. The counter could be in the 'item' or an explicit argument. The 'recursion depth' counter may or may not be the same thing as a 'hop count' that could be kept in the mbuf. it is possible both make sense two mbuf counters. one oncremented whenever there is am mbuf handoff that doesn't involve queueing, and is cleared to 0 whenever queueing is invoked, and one that is continually incremented until the packet leaves the machine.. one to stop packets permanently circulating around a machine and one for stack protection..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?470075EE.1030104>