cvs commit: src/sys/kern kern_sig.c

[David Schultz]

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.