Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 3 Mar 2005 09:54:07 -0500
From:      John Baldwin <jhb@FreeBSD.org>
To:        freebsd-arch@FreeBSD.org
Cc:        David Schultz <das@FreeBSD.org>
Subject:   Re: Removing kernel thread stack swapping
Message-ID:  <200503030954.08271.jhb@FreeBSD.org>
In-Reply-To: <20050303074242.GA14699@VARK.MIT.EDU>
References:  <20050303074242.GA14699@VARK.MIT.EDU>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200503030954.08271.jhb>