Date: Thu, 3 Mar 2005 08:58:25 -0800 From: Brooks Davis <brooks@one-eyed-alien.net> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org Subject: Re: Removing kernel thread stack swapping Message-ID: <20050303165825.GB4737@odin.ac.hmc.edu> In-Reply-To: <200503030954.08271.jhb@FreeBSD.org> References: <20050303074242.GA14699@VARK.MIT.EDU> <200503030954.08271.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050303165825.GB4737>