From owner-freebsd-arch@FreeBSD.ORG  Sun Sep 30 18:45:49 2007
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id CEC8116A41A;
	Sun, 30 Sep 2007 18:45:49 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: from elvis.mu.org (elvis.mu.org [192.203.228.196])
	by mx1.freebsd.org (Postfix) with ESMTP id 4B6CA13C447;
	Sun, 30 Sep 2007 18:45:49 +0000 (UTC)
	(envelope-from bright@elvis.mu.org)
Received: by elvis.mu.org (Postfix, from userid 1192)
	id 759BF1A4D80; Sun, 30 Sep 2007 11:24:27 -0700 (PDT)
Date: Sun, 30 Sep 2007 11:24:27 -0700
From: Alfred Perlstein <alfred@freebsd.org>
To: Alexander Motin <mav@FreeBSD.org>
Message-ID: <20070930182427.GY53439@elvis.mu.org>
References: <46FFD850.1040508@FreeBSD.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <46FFD850.1040508@FreeBSD.org>
User-Agent: Mutt/1.4.2.3i
Cc: freebsd-arch@freebsd.org
Subject: Re: Kernel thread stack usage
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion related to FreeBSD architecture <freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Sep 2007 18:45:49 -0000

* Alexander Motin <mav@FreeBSD.org> [070930 11:09] 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?

Not that I know of, but one could defer to queueing once the chain
gets to a certain length.

-- 
- Alfred Perlstein