cvs commit: src/sys/kern kern_sig.c

[David Xu]

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
make it run happily! but I can quickly find an application that adding
another extra 20M still does not make sense, for example, java application!
when system is under swapping, no one expects it will be high performance!
an excellent system can only use 70% machine resource under heavy swapping,
but many people will normally can not accept reduced service quality, only
technical people can understand the problem.

> It's not about convenience or taking the easy way out.  Let's fix
> sigwait() to have the proper assumptions and go from there.  I'm
> inclined to agree with John that the problem is not widespread or
> impossible to track down.

this is not an acceptable sentence to me,  there is still possible, right?

> Fixing it is not hard either, we already have
> the PHOLD()/PRELE() functions for doing exactly what is needed here.
>

PHOLD/PRELE is not a good choice to me, in critical path, because it needs
proc lock (sounds a giant lock to a process), there is lock order reversal,
and at a hot path, it adds another lock contention. I only want a simple 
flag
PNOSWAP to msleep if the swapping code really can not be eliminated.
I am also unhappy that a thread holding a mutex can be preempted,
why do you want to preempt a thread while holding some mutexes, and
switch away and then switch back quickly when other threads can not get
these locks, this is a bit out of topic of course.

> Scott
>
>