From owner-cvs-all@FreeBSD.ORG Fri Mar 4 18:40:48 2005 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0178016A4CF; Fri, 4 Mar 2005 18:40:48 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC8C343D2D; Fri, 4 Mar 2005 18:40:46 +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 j24IgfrK012024; Fri, 4 Mar 2005 11:42:41 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <4228AB27.3020204@samsco.org> Date: Fri, 04 Mar 2005 11:38:31 -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 Schultz References: <200503021343.j22DhpQ3075008@repoman.freebsd.org> <200503020915.28512.jhb@FreeBSD.org> <4226446B.7020406@freebsd.org> <61ac46c154aa515a692308440dd1141d@FreeBSD.org> <422710DD.1070203@freebsd.org> <422719E0.10703@samsco.org> <42279B6D.1000005@freebsd.org> <20050304182629.GA39457@VARK.MIT.EDU> In-Reply-To: <20050304182629.GA39457@VARK.MIT.EDU> 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: cvs-all@FreeBSD.org cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: David Xu cc: John Baldwin Subject: Re: cvs commit: src/sys/kern kern_sig.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 18:40:48 -0000 David Schultz wrote: > 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. That's close to my position too. I think it would be useful to investigate adding diagnostics to catch the unknown cases instead of just letting them turn into mystery panics. Scott