From owner-freebsd-current@FreeBSD.ORG Fri Mar 4 01:50:35 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9710116A4CE; Fri, 4 Mar 2005 01:50:35 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B068543D66; Fri, 4 Mar 2005 01:50:30 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j241qVGp007535; Thu, 3 Mar 2005 18:52:31 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4227BE61.1080805@samsco.org> Date: Thu, 03 Mar 2005 18:48:17 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Xu References: <200503040103.j2413CNr082179@apollo.backplane.com> <4227B7F8.9090304@freebsd.org> In-Reply-To: <4227B7F8.9090304@freebsd.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: alc@freebsd.org cc: freebsd-current@freebsd.org cc: Robert Watson cc: peter@freebsd.org Subject: Re: FreeBSD 5.3 crash (core with debug symbols available) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 01:50:35 -0000 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