Date: Fri, 07 Jul 2000 15:03:43 -0600 From: Chuck Paterson <cp@bsdi.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Doug Rabson <dfr@nlsystems.com>, Greg Lehey <grog@lemis.com>, David Greenman <dg@root.com>, freebsd-smp@freebsd.org Subject: Re: Spin Locks, blocking interrupts, and ipending Message-ID: <200007072103.PAA16442@berserker.bsdi.com>
index | next in thread | raw e-mail
}
} For ipending it IS the same category. At least for i386. If you look at
} the patchset you will see that the ipending code I wrote
} is 100% MP safe.
It may be true that ipending itself is safe, but
1) Wrapping all the code in Giant isn't the same as being MP safe.
Especially when the code to acquire Giant just can work
at the start of an interrupt stub.
2) If you ever have a second processor you will soon get to
mtp->mtx_lock = newv;
panic("blocking"); <----
mtx_enter(&SchedMutex, MTX_SPIN);
3) The code which deals with masking interrupts in the
hardware has to be MP aware. Functions like Xresume
may happen on multiple processors at the same time,
at least once stuff moves out from under Giant.
}
} We had (and have) code strewn all over the FreeBSD to deal with the
} APIC. It's a mess, and a mistake. A few strategic places, sure,
} but everywhere? No.
}
You definitely don't need the code strewn all over the place. There
is no reason it can't be encapsulated.
} For example, take the case where you want to tie a NIC interrupt to
} a particular cpu. You could tie the interrupt and simply leave it
} that way, and if the interrupt occurs at an inopportune time the
} interrupt vector code can choose what to do:
}
What exactly do you mean by tie an interrupt to a particular
CPU? Route in hardware, is the really possible on X86?
Route in software?
} * set ipending and return (the interrupt will be run the moment
} the scheduler lock is released)
For an edge triggered device you need to do more than set ipending.
You need to muck with the hardware. You will need pcpu ipending
if you want to cause it to run on a particular processor
}
} * forward the interrupt to another cpu
}
} * do something else...
}
Chuck
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200007072103.PAA16442>