Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 03 Mar 2005 18:48:17 -0700
From:      Scott Long <scottl@samsco.org>
To:        David Xu <davidxu@freebsd.org>
Cc:        peter@freebsd.org
Subject:   Re: FreeBSD 5.3 crash (core with debug symbols available)
Message-ID:  <4227BE61.1080805@samsco.org>
In-Reply-To: <4227B7F8.9090304@freebsd.org>
References:  <Pine.NEB.3.96L.1050303133720.80219D-100000@fledge.watson.org> <200503040103.j2413CNr082179@apollo.backplane.com> <4227B7F8.9090304@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
David Xu wrote:
> Matthew Dillon wrote:
> 
>>    The main reason we no longer swap the kernel stack is because there 
>> are
>>    a whole lot of things we put on local thread stacks that other 
>> parts of the
>>    system may reference even while the process is blocked.  e.g. token 
>>    references, message structures, register or FP save state, and so 
>> forth.
>>    I also intend to put cache related structures, such as range locks, on
>>    the stack.  I just didn't want to have to worry about it.
>>
>>    Besides, it only happened when a process was actually *SWAPPED* 
>> out, not
>>    just heavily paged, and how often does *that* happen these days?  Even
>>    on a heavily loaded system only a handful of processes, mostly getty's
>>    and long-idle interactive shells, might actually be swapped out.  This
>>    makes the memory savings minimal at best.
>>
>>  
>>
> I always worry about swapping out kernel stack. my lastest kernel umtx 
> code is broken by this.
> I can not agree that per-mutex operation needs a pair of heavy malloc 
> and free call, if kernel
> mutex performance is important, why userland mutex shouldn't be ? If I 
> have to use malloc,
> I am afraid that I have to do more extra work than Linux does, I will 
> fail under real world
> benchmark like super-smack etcs.
> 

Can you provide a reference for the umtx problem?  There might be a 
reasonable solution.

Scott



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4227BE61.1080805>