From owner-freebsd-arch Thu Dec 20 12:16:31 2001 Delivered-To: freebsd-arch@freebsd.org Received: from mail12.speakeasy.net (mail12.speakeasy.net [216.254.0.212]) by hub.freebsd.org (Postfix) with ESMTP id 2C8C237B41B for ; Thu, 20 Dec 2001 12:16:26 -0800 (PST) Received: (qmail 22259 invoked from network); 20 Dec 2001 20:16:25 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([64.81.54.73]) (envelope-sender ) by mail12.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 20 Dec 2001 20:16:25 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <600.1008837822@critter.freebsd.dk> Date: Thu, 20 Dec 2001 12:16:08 -0800 (PST) From: John Baldwin To: Poul-Henning Kamp Subject: RE: Kernel stack size and stacking: do we have a problem ? Cc: arch@freebsd.org Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 2. Do we in general want to incur the overhead of scheduling > in stacking layers or does increasing the kernel stack as > needed make more sense ? I prefer a method where by when you call into each level, you check enough_stack(), and if it fails, you queue the request so a worker kthread can handle it and wakeup you up with the completion status stored in the item you just queued. This lets us call down directly into the stack as far as we can, but then bail to the asynch model if we run out of stack. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message