Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 Nov 2000 03:18:48 +1100 (EST)
From:      Bruce Evans <bde@zeta.org.au>
To:        Jake Burkholder <jburkhol@home.com>
Cc:        John Baldwin <jhb@FreeBSD.ORG>, smp@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/kern kern_timeout.c 
Message-ID:  <Pine.BSF.4.21.0011190234500.337-100000@besplex.bde.org>
In-Reply-To: <20001118025912.158D4BA7A@io.yi.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0011190234500.337-100000>