From owner-freebsd-smp Fri Nov 17 9:30:10 2000 Delivered-To: freebsd-smp@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 7F25B37B479 for ; Fri, 17 Nov 2000 09:30:07 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAHHTnB94337; Fri, 17 Nov 2000 09:29:50 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <20001117052556.5F927BA7A@io.yi.org> Date: Fri, 17 Nov 2000 09:30:31 -0800 (PST) From: John Baldwin To: Jake Burkholder Subject: Re: cvs commit: src/sys/kern kern_timeout.c Cc: cp@bsdi.com, smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 17-Nov-00 Jake Burkholder wrote: >> Well, when I tried this the machine hung on the first fast interrupt handler >> it >> ran, so it doesn't look like this approach works either. :-/ I've tried >> splitting up p_procq into p_runq, p_sleepq, and p_mtxq (for processes >> blocked >> on a mutex), but while those kernels boot ok and seem to sort of run, I end >> up >> with hung processes. If I (or anyone else) don't have a good solution for >> this, >> then I think I will back out the changes to move Giant out of mi_switch() >> tomorrow afternoon until we have a solution for this. > > 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. I was merely doing it for completeness, but my SMP machines would end up with hung processes, though the machines are running ok. > 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. That would be ok. I also used NOSWITCH because we are about to call mi_switch() anyways. However, go ahead and do that change. > 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. Yes. I have a few other patches for swtch.s, but the rest of your patch looks great, so go ahead and commit it. I'll commit my swtch.s fixes in a sec. Glad to see that school isn't keeping you too busy now. :) > Jake -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message