cvs commit: src/sys/kern kern_sig.c

[Scott Long]

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.

Scott