From owner-cvs-src@FreeBSD.ORG Fri Mar 4 19:20:39 2005 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E8D1416A4CE; Fri, 4 Mar 2005 19:20:38 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9290843D54; Fri, 4 Mar 2005 19:20:38 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id A4D837A41E; Fri, 4 Mar 2005 11:20:36 -0800 (PST) Message-ID: <4228B504.7000302@elischer.org> Date: Fri, 04 Mar 2005 11:20:36 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en, hu MIME-Version: 1.0 To: Scott Long 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> <4228AB27.3020204@samsco.org> In-Reply-To: <4228AB27.3020204@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: src-committers@FreeBSD.org cc: John Baldwin cc: cvs-src@FreeBSD.org cc: cvs-all@FreeBSD.org cc: David Xu cc: David Schultz Subject: Re: cvs commit: src/sys/kern kern_sig.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2005 19:20:39 -0000 Scott Long wrote: > 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. for a start I'd like to add a sysctl to turn off swapping out kernel stacks.. then if someone had a reproducible or atleast 'common" problem, we could suggest turning it off to see if it fixes the problem.. that would be a big smoking gun.. > > Scott