cvs commit: src/sys/kern kern_sig.c

Julian Elischer julian at
Fri Mar 4 19:20:39 GMT 2005

Scott Long wrote:

> David Schultz wrote:
>> On Fri, Mar 04, 2005, David Xu wrote:
>>> Scott Long wrote:
>>>> David Xu wrote:
>>>>> John Baldwin wrote:
>>>>>> Note that swapping out the stack is the default behavior in 4.x, so
>>>>>> I actually think that the million lines of kernel code are indeed
>>>>>> safe, only sigwait() is broken and should be fixed. :)
>>>>> Many 4.x programming skill can not be applied to FreeBSD current,
>>>>> they are so different, most of code in kern/ seems be completely
>>>>> rewritten. :=)
>>>>> David Xu
>>>> I think you're making a much bigger deal out of this than it needs to
>>>> be.  Swapping the kernel stacks is important on real production 
>>>> systems.
>>>> FreeBSD has always been much better at handling low-memory situations
>>>> that most other OSes, and it's one of the things that has kept it
>>>> relevant in the server area.  A few 16K chunks might not seem like 
>>>> a lot
>>>> on a desktop system, but when you're talking about a server with
>>>> hundreds of ithreads and hundreds of user processes, it matters a 
>>>> quite
>>>> a bit.  Also, there is talk about increasing the default kstack 
>>>> size due
>>>> to all of the extra inlining that the compiler does with the -O2 
>>>> option
>>>> and the large recursion problems in the softdep code.  If we do this,
>>>> then being able to swap them out gets even more important.
>>> I think your system is just a point that adding another 10M bytes 
>>> memory
>> [...]
>> I suspect that the performance difference is not as great as some
>> people think, but the *real* question in my mind is:
>>     Is there actually more than one instance of this bug?
>> In 4.X, it's pretty clear that we got things right.  But I haven't
>> had time to follow KSE and other large projects since then to know
>> what developers thought the rules were when they wrote the code.
>> If there are problems of this nature all over the place, then
>> eliminating kstack swapping would be an easy way to bring the
>> reliability of 5.X closer to where we were with 4.X.  But if there
>> is only one bug, then it would be disingenuous to use it as an
>> excuse to kill a feature that has worked since day one.
> That's close to my position too.  I think it would be useful to
> investigate adding diagnostics to catch the unknown cases instead
> of just letting them turn into mystery panics.

for a start I'd like to add a sysctl to turn off swapping out kernel 
then if someone had a reproducible or atleast 'common" problem,
we could suggest turning it off to see
if it fixes the problem.. that would be a big smoking gun..

> Scott

More information about the cvs-src mailing list