Date: Tue, 26 Feb 2002 00:14:47 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Bruce Evans <bde@zeta.org.au> Cc: John Baldwin <jhb@FreeBSD.ORG>, <current@FreeBSD.ORG>, Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>, Bosko Milekic <bmilekic@unixdaemons.com>, Alfred Perlstein <alfred@FreeBSD.ORG>, Terry Lambert <tlambert2@mindspring.com> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <200202260814.g1Q8ElX57457@apollo.backplane.com> References: <20020226185416.P43865-100000@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> The critical section stuff currently in current is part of the original
:> preemption patches I wrote at Usenix last year. They aren't in the tree
:> because they aren't stable yet. We still have problems on the alpha and
:> problems with IPI deadlocks on SMP machines that need to be worked out. Since
:> this API is still very much in flux I'd prefer to keep it simple for now and
:> not make the code overly complex with optimizations until after we have settled
:> on the design.
:
:The change is mostly part of the design change needed to un-break fast
:interrupt handlers. critical_enter() mask not mask hardware
:interrupts for the same reason than splhigh() must not mask them:
:there is too much MI code that thinks it is critical and short but
:really isn't (e.g., everything under spinlocks in -current). Changing
:cpu_critical_enter() to a null version to prevent spinlocks masking
:interrupts doesn't work very well because it is used for other things
:that really do need to mask interrupts. Having 2 levels for
:cpu_critical_enter() (on that masks normal interrupts and one that
:masks fast interrupts) would work but I think there are already too
:many levels of critical_enter()s.
:
:Bruce
Not to mention the fact that this will lead to an ability to break
into the debugger via the serial concsole even if the code is stuck
in a spin mutex or in the middle of the scheduler. Not with this
commit or the followup cleanup commit, not quite, but maybe the one
after. It puts us on the right road.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202260814.g1Q8ElX57457>