From owner-freebsd-arch@FreeBSD.ORG Thu Mar 3 16:58:26 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A10AA16A4CE; Thu, 3 Mar 2005 16:58:26 +0000 (GMT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 31BEC43D55; Thu, 3 Mar 2005 16:58:26 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j23GwPr8014802; Thu, 3 Mar 2005 08:58:25 -0800 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j23GwPUC014801; Thu, 3 Mar 2005 08:58:25 -0800 Date: Thu, 3 Mar 2005 08:58:25 -0800 From: Brooks Davis To: John Baldwin Message-ID: <20050303165825.GB4737@odin.ac.hmc.edu> References: <20050303074242.GA14699@VARK.MIT.EDU> <200503030954.08271.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="XF85m9dhOBO43t/C" Content-Disposition: inline In-Reply-To: <200503030954.08271.jhb@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu cc: David Schultz cc: freebsd-arch@freebsd.org Subject: Re: Removing kernel thread stack swapping X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 16:58:26 -0000 --XF85m9dhOBO43t/C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Mar 03, 2005 at 09:54:07AM -0500, John Baldwin wrote: > On Thursday 03 March 2005 02:42 am, David Schultz wrote: > > Any objections to the idea of removing the feature of swapping out > > kernel stacks? Unlike disabling UAREA swapping, this has the > > small downside that it wastes 16K (give or take a power of 2) of > > wired memory per kernel thread that we would otherwise have > > swapped out. However, this disadvantage is probably negligible by > > today's standards, and there are several advantages: > > > > 1. David Xu found that some kernel code stores externally-accessible > > data structures on the stack, then goes to sleep and allows the > > stack to become swappable. This can result in a kernel panic. >=20 > He found one instance. >=20 > > 2. We don't know how many instances of the above problem there are. > > Selectively disabling swapping for the right threads at the > > right times would decrease maintainability. >=20 > Probably 1. Note that since at least FreeBSD 1.0 programmers have had to= =20 > realize that the stack can be swapped out. The signal code in pre-5.x st= ores=20 > part of the signal state in struct proc directly in order to support swap= ped=20 > out stacks. In 5.x we just malloc the whole signal state directly since = we=20 > killed the u-area. sigwait() has a bug that should be fixed, let's not= =20 > engage in overkill and throw the baby out with the bath water. In genera= l we=20 > need to discourage use of stack variables anyway because when people use= =20 > stack space rather than malloc() space the failure case for running out i= s=20 > much worse, i.e. kernel panic when you overflow your stack (even though K= VM=20 > may be available) vs. waiting until some memory is available or returning= =20 > NULL. >=20 > Hence, don't kill this whole feature just because someone is too lazy > to fix a bug. It would be very useful and informative if someone were to write a high level description of the ways in which the kernel is not a POSIX C programming environment. In addition to providing somewhere to point people who wonder why -lbigcomplicatedlibrary doesn't work with their kernel source, such a list would force us to enumerate those differences and make sure they are based on design decisions that make sense. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --XF85m9dhOBO43t/C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCJ0IxXY6L6fI4GtQRAgK6AJ94dNJWmBRGqdlSTsIYpGDEv4qSwQCfZyiV Qkn4jkSplCvp6PCCZXnRKBY= =Fjes -----END PGP SIGNATURE----- --XF85m9dhOBO43t/C--