From owner-freebsd-smp Fri Nov 17 7:23:48 2000 Delivered-To: freebsd-smp@freebsd.org Received: from zibbi.icomtek.csir.co.za (zibbi.icomtek.csir.co.za [146.64.24.58]) by hub.freebsd.org (Postfix) with ESMTP id 9BF4637B4C5; Fri, 17 Nov 2000 07:23:38 -0800 (PST) Received: (from jhay@localhost) by zibbi.icomtek.csir.co.za (8.11.0/8.11.0) id eAHFNEV94801; Fri, 17 Nov 2000 17:23:14 +0200 (SAT) (envelope-from jhay) From: John Hay Message-Id: <200011171523.eAHFNEV94801@zibbi.icomtek.csir.co.za> Subject: Re: cvs commit: src/sys/kern kern_timeout.c In-Reply-To: <20001117052556.5F927BA7A@io.yi.org> from Jake Burkholder at "Nov 16, 2000 09:25:56 pm" To: jburkhol@home.com (Jake Burkholder) Date: Fri, 17 Nov 2000 17:23:14 +0200 (SAT) Cc: jhb@FreeBSD.ORG (John Baldwin), smp@FreeBSD.ORG, cp@bsdi.com X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > Hmm. This is unfortunate because the change to mi_switch is absolutely > necessary. I don't see why changing the queues would cause problems. > The p_runq/p_mtxq isn't really necessary because they are mutually > exclusive, like the runq/sleepq used to be. > > Looking at the use of DROP_GIANT_NOSWITCH, I think that it should be > after the mtx_enter(&sched_lock, MTX_SPIN) instead of before. The idea > with the noswitch flag is that it allows you to release a sleep mutex > with interrupts disabled, otherwise there's no point. If interrupts are > enabled you're supposed to be able to block. > > Here's a patch that seems to work ok here. It works on my UP box running > X and stuff, I don't notice any hung processes. It works on the SMP box, > I built a kernel over NFS and it seemed ok, except that I can't > get a kernel to boot using the serial console with WITNESS enabled. It > stops at the twiddle thing before the copyright is printed and just hangs. > This also happens without the patch and even with a UP kernel, so I don't > really know what's going on. Please try and let me know if you still > see the hung processes. > > I think we'll just have to settle with no longer being able to assert > that a process has no wchan in cpu_switch. There's bound to be alot of > contention with Giant, but eventually signals should be protected by > a per-process mutex, so a context switch at that point is less likely. > Well I have tried your patch and so far it looks good. I have finished a "make -j13 world" and a "make release NODOC=YES WORLD_FLAGS=-j4" with no problems on a dual 266MHz PII. John -- John Hay -- John.Hay@icomtek.csir.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message