Date: Mon, 25 Feb 2002 23:42:41 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: John Baldwin <jhb@FreeBSD.org> Cc: 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>, Bruce Evans <bde@zeta.org.au> Subject: Re: Patch for critical_enter()/critical_exit() & interrupt assem Message-ID: <200202260742.g1Q7gfi57160@apollo.backplane.com> References: <XFMail.020226023229.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:1) I had an ugly panic testing it on the alpha. After a good deal of sleuthing,
: I've determined that we still have some preemption related bugs in possibly
: the alpha pmap, but that td_ucred isn't the problem.
:2) I've been thinking about the Giant instrumentation a bit. I figured out that
: most of my problems were with the implementation and have come up with some
: ideas that might make it a bit more scalable and easier from a long-term
: perspective though I think it still has some scaling issues.
This is precisely the problem. You are making so many modifications
in your local tree that NONE of the work winds up getting committed for
months and months.
:In regards to the critical section stuff:
:
: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.
:
:You've brought up some issues with the critical section stuff as far as its
:assumptions in fork_exit() and a few other places. For now I would prefer to
:leave that code alone as it works with our current model. However, I am
:interested in fixing assumptions that would allow the cpu_critical_enter/exit
:API to be changed but still maintain an MI interface. This could mean changing
:the API for cpu_critical_enter/exit and possibly the API (perhaps some MD
:macros?) for the fork_exit() fixup code.
:
:
:John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/
I'm sorry John, but I am going to go ahead with my commit. I strongly
disagree with your premise and, frankly, my changes clean the code up
rather then make it more complex. You have your fingers in just about
every single goddamn file in the system and you and others have cried
wolf one too many times. I am through with playing that game.
The commit goes in. I am open to any suggestions you have for stage-2,
which will be a furtherance of the cleanup, but I absolutely refuse to
allow you to prevent me from contributing to the SMP work in -current
for a forth time because it doesn't exactly match your dream or
N-month-old stale patches you might have sitting around in P4.
-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?200202260742.g1Q7gfi57160>