:This sort of concerns me, but if I remeber correctly, unmasking
:spl will cause a soft intr if there are pending interupts, the only
:problem is that completely software initiated interupts wouldn't
:get processed, or would they? Can you explain how they are being
:scheduled/run if you remove doreti()? One alternative would be to
:call doreti() only in the syscalls with the MPunsafe flag set,
:although I'm probably missing something that makes doreti() totally
:unnessesary, it may be that clock interupts are covering your
:removal of doreti().
Ditto on the concern. I almost have the second version of the patch ready,
which cleans up a huge number of accretions from things
people were testing but never finished. I've removed _cil and _cml,
I've removed all the _LOCK macros that all devolve down into the mp_lock
and simply have them call get_mplock. I've removed the sti code in
MPgetlock_edx which was there solely to deal with one case in swtch.s
where interrupts weren't enabled at the time the MP lock was attempted
(interrupts have to be enabled when spinning on the MP lock in order
to be able to take IPI's, so things like cpu shutdowns work). Actually,
that's the one piece I still haven't fixed all the cases for that's
holding up the second patch. 'reboot' isn't working right due to IPI's
not getting through :-).
With all the cleanups and the weirder conditional code removed, it's
become a whole lot more readable and the doreti picture is becoming much
clearer. I think, at worst, I may be missing an AST check there.
I have created a document outlining a 'new' SMP mechanism proposal,
with emphasis on the interrupt handling (keep in mind that most
interrupts will be synchronously switched to or use the BSDI mechanism,
so overhead is not as bad as it may seem to a layperson). I haven't
implemented the interrupt mechanism yet - doh! That's a lot work :-),
but I have removed all the weird interrupt optimizations that were in
there before that don't make much sense with regards to the direction
we appear to be heading for interrupt handling.
http://www.backplane.com/FreeBSD4/smp-api.html
:FYI, I was tempted to commit this with "Submitted by: dillon" and
:watch the fur fly, it is 5.0 after all. :)
:
:As things progress I think multi-subsystem locks expressing intent
:for structure manipulation would be a very cool idea, although I
:need to think about it more.
:
:thanks,
:-Alfred
Well, as implemented in the interrupt, trap, and syscall code this
idea is a failure. It doesn't help the critical path at all (it can't,
since you are still causing L1 cache invalidations on every entry!).
It's all gone in the new patch.
I think there is definitely a place for per-structure spinlocks,
especially in non-blocking situations (think: the critical path in
the signal mask code). But it's too early to discuss that.
-Matt
Matthew Dillon
<[EMAIL PROTECTED]>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
