From owner-freebsd-current@FreeBSD.ORG Thu Mar 3 13:43:56 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4622616A4CE; Thu, 3 Mar 2005 13:43:56 +0000 (GMT) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E12A43D49; Thu, 3 Mar 2005 13:43:56 +0000 (GMT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with SMTP id 93F1646B20; Thu, 3 Mar 2005 08:43:55 -0500 (EST) Date: Thu, 3 Mar 2005 13:41:53 +0000 (GMT) From: Robert Watson X-Sender: robert@fledge.watson.org To: David Xu In-Reply-To: <42269B85.3050602@freebsd.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: alc@FreeBSD.org cc: freebsd-current@freebsd.org cc: peter@FreeBSD.org Subject: Re: FreeBSD 5.3 crash (core with debug symbols available) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 13:43:56 -0000 On Thu, 3 Mar 2005, David Xu wrote: > >The consensus on IRC is that threads should not use their stacks for > >anything but storage of their own variables. Anything used for > >synchronization or state should be placed in malloc()d memory or some > >other shared structure. > > Stack variable is cheap and fastest, why should I use slow malloc ? So you don't page fault, of course :-). > >I'll start working on a patch to change these references in the sigwait() > >family. And queue up a pointy hat to jeff@. Pointers to other badly > >behaved code gladly accepted :) > > This is not a bug, I always perfer to use stack variable because there > is no lock order reversal and have to work around it. If I am correct, > Linux and DragonFly both disable kernel stack to be swapped out. There was a time where the swapping out of kernel thread stacks under load made a significant difference under high memory pressure. The question is whether that's still true enough to justify the overhead and complications it presents today. For one thing, we pay several extra mutex operations per page fault to prevent swapping of the kernel stack in memory during the fault. And I'm sure this is not the only situation where we have a latent bug involving paged out kernel stacks and structures getting hooked to global lists. Robert N M Watson