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
[-- Attachment #1 --] 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. > > He found one instance. > > > 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. > > Probably 1. Note that since at least FreeBSD 1.0 programmers have had to > realize that the stack can be swapped out. The signal code in pre-5.x stores > part of the signal state in struct proc directly in order to support swapped > out stacks. In 5.x we just malloc the whole signal state directly since we > killed the u-area. sigwait() has a bug that should be fixed, let's not > engage in overkill and throw the baby out with the bath water. In general we > need to discourage use of stack variables anyway because when people use > stack space rather than malloc() space the failure case for running out is > much worse, i.e. kernel panic when you overflow your stack (even though KVM > may be available) vs. waiting until some memory is available or returning > NULL. > > 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 -- 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCJ0IxXY6L6fI4GtQRAgK6AJ94dNJWmBRGqdlSTsIYpGDEv4qSwQCfZyiV Qkn4jkSplCvp6PCCZXnRKBY= =Fjes -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050303165825.GB4737>