cvs commit: src/sys/kern kern_sig.c

Julian Elischer julian at elischer.org
Thu Mar 3 20:43:54 GMT 2005



David Xu wrote:

> David Schultz wrote:
>
>> On Thu, Mar 03, 2005, Mike Silbersack wrote:
>>  
>>
>>> On Thu, 3 Mar 2005, David Schultz wrote:
>>>
>>>   
>>>
>>>> Of course, there's another possible solution which is to remove
>>>> the swapping code entirely.  That would certainly simplify things,
>>>> but it would also make FreeBSD degrade less gracefully under load.
>>>>     
>>>
>>> I don't think that would be a big loss; by the time you're doing a 
>>> lot of process swapping, you're pretty screwed.
>>>
>>> A process has to be swapped back in in order for it to be killed, 
>>> right? We might be better off without swapping, in that case.
>>>   
>>
>>
>> Yeah, with 16K kernel stacks, you'd have to swap a lot of threads
>

16K!!
we used to run on 4k, and that was with interrupts using the stack as well..
now we a e not doing that..
we should look at stack usage and get it back to 8K at most! :-)   (on x86)

>> to make a big difference in the amount of wired memory in the
>> system.  KSE helps with this, because processes with thousands of
>> user threads don't have thousands of kernel threads.
>>
>>  
>>
> This only happens at comparative idle time, if the process is a heavy  
> I/O bound process,
> this does not help.


assuming that all those threads are doing IO.

>
>> Another thing that swapping does, though, is prevent some
>> processes from running for a while when the system is under load,
>> thereby reducing contention for resources and allowing the other
>> processes to get things done.  If people decide to go this way, it
>> might be a good idea to keep the second feature.  It costs very
>> little in terms of complexity because no actual swapping is done.
>> But who knows?  Maybe nobody cares about this, either...
>>
>>  
>>
> I would like to not swap out kernel stack, it allows me to write some 
> speedy code,
> this is my personal favorit. :=)


I think that swapping kernel stacks may be an idea who's time has passed.



More information about the cvs-src mailing list