Date: Fri, 06 Dec 1996 10:04:38 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: Terry Lambert <terry@lambert.org> Cc: smp@csn.net (Steve Passe), ccsanady@friley216.res.iastate.edu, smp@freebsd.org Subject: Re: make locking more generic? Message-ID: <199612060204.KAA11744@spinner.DIALix.COM> In-Reply-To: Your message of "Thu, 05 Dec 1996 11:37:58 MST." <199612051837.LAA19621@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Terry Lambert wrote:
> > So whenever a CPU acquires the lock I have
> > the code set the priority of that CPU to "VERY LOW". So now all pending I
NTs
> > will be sent to it, which it can deal with since it already holds the lock.
> > When a CPU releaes the lock it resets its priority to "NORMAL".
> >
> > The problem is that whenever a CPU gets an INT its PPR is increased to
> > the priority of the INT, thus negating the "VERY LOW" prio I set in the
> > TPR. So if a CPU is behind the lock because of an INT it WON'T get
> > sent other pending INTs, the other CPU will. Now that we have IPIs
> > working I hope to be able to send an IPI to the other CPUs telling them to
set
> > their TPR to "VERY HIGH", thus dis-abling them from getting INTs.
>
> I don't understand.
>
> If CPU 1 is servicing INT 12 from a disk controller, and you get INT 4
> from a serial port, don't you *want* CPU 2 to service the INT 4 in
> parallel???
Yes, it would be nice, **if** the second cpu can enter the kernel. Since
it can't at present, it has to wait for the first cpu to leave. However
if the cpu that was servicing the interrupt in the first place gets
the irq4, it can process it immediately.
>
> Terry Lambert
> terry@lambert.org
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612060204.KAA11744>