From owner-freebsd-smp Sat Nov 18 8:31:45 2000 Delivered-To: freebsd-smp@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 3ADB637B479; Sat, 18 Nov 2000 08:31:40 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id DAA16353; Sun, 19 Nov 2000 03:18:50 +1100 Date: Sun, 19 Nov 2000 03:18:48 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Jake Burkholder Cc: John Baldwin , smp@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_timeout.c In-Reply-To: <20001118025912.158D4BA7A@io.yi.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 17 Nov 2000, Jake Burkholder wrote: > > > > On 18-Nov-00 John Baldwin wrote: > > > > > > On 18-Nov-00 John Baldwin wrote: > > >> jhb 2000/11/17 16:21:01 PST > > >> > > >> Modified files: > > >> sys/kern kern_timeout.c > > >> Log: > > >> Release sched_lock very briefly to give interrupts a chance to fire if we > > >> are in softclock() for a long time. The old code already did an > > >> splx()/slphigh() pair here, I just missed adding in the equivalent mutex > > >> operations on sched_lock earlier. I fixed this too. > > > Before this I could get processes to hang (the box was still up, but one > > > process was stuck, tying up its pty) though the box was still fine (I could > > > login and do stuff) if I ran a buildworld -j X where X > 1. With this I > > > built > > > a kernel with -j 8 and am currently chugging through a -j 64 world. > > > > Grrrr. Spoke too soon. :( It took longer, but I have one hung process (though The fix should only affect interrupt latency. When sched_lock isn't released, softclock() will exit after checking the buckets for each tick value between the initial value of softticks and the final value of `ticks'. Then interrupts are unlocked and the next call to softclock() will handle any new timeout expiries. Losing the race to check for all timeout expiries before returning is unimportant. > I think the APM_FIXUP_CALLTODO thing has rotted, its based on the > old delta queue timeout implementation. It rotted 3 months before it was committed in -current. I didn't remove it because the bug (?) that it fixes are still there. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message