14 messages in org.freebsd.freebsd-archRemoving kernel thread stack swapping| From | Sent On | Attachments |
|---|---|---|
| David Schultz | Mar 3, 2005 7:42 am | |
| Ryan Sommers | Mar 3, 2005 2:12 pm | |
| David Xu | Mar 3, 2005 2:37 pm | |
| Scott Long | Mar 3, 2005 2:51 pm | |
| John Baldwin | Mar 3, 2005 2:52 pm | |
| David Schultz | Mar 3, 2005 3:35 pm | |
| M. Warner Losh | Mar 3, 2005 4:47 pm | |
| Stephan Uphoff | Mar 3, 2005 4:51 pm | |
| Brooks Davis | Mar 3, 2005 4:58 pm | |
| David Xu | Mar 3, 2005 11:29 pm | |
| Scott Long | Mar 4, 2005 12:34 am | |
| Christoph Hellwig | Mar 5, 2005 9:17 am | |
| Peter Wemm | Mar 15, 2005 5:43 pm | |
| Stephan Uphoff | Mar 15, 2005 7:19 pm |
| Subject: | Removing kernel thread stack swapping | |
|---|---|---|
| From: | Brooks Davis (bro...@one-eyed-alien.net) | |
| Date: | Mar 3, 2005 4:58:08 pm | |
| List: | org.freebsd.freebsd-arch | |
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