Date: Tue, 26 Feb 2002 02:32:29 -0500 (EST) From: John Baldwin <jhb@FreeBSD.org> To: Matthew Dillon <dillon@apollo.backplane.com> 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: <XFMail.020226023229.jhb@FreeBSD.org> In-Reply-To: <200202260314.g1Q3E5055315@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 26-Feb-02 Matthew Dillon wrote: > >: >:On Mon, 25 Feb 2002, Matthew Dillon wrote: >: >:> Unless an unforseen problem arises, I am going to commit this tomorrow >:> and then start working on a cleanup patch. I have decided to >: >:Please wait for jhb's opinion on it. He seems to be offline again. >:I think he has plans and maybe even code for more code in critical_enter(). >:I think we don't agree with these plans, but they are just as valid >:as ours, and our versions undo many of his old changes. > > I am not going to predicate my every move on permission from JHB nor > do I intend to repeat the last debacle which held-up (and is still > holding > up) potential commits for a week and a half now. JHB hasn't even > committed *HIS* patches and I am beginning to wonder what the point is > when *NOTHING* goes in. If he had code he damn well should have said > something on the lists two days ago. As it is, I have invested a great > deal of time and effort on this patch and it is damn well going to go > in so I can move on. I've been taking the weekend off so I could have some think to cool off and think and not get all emotional. The reasons I haven't committed the td_ucred stuff are: 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. 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. > -Matt -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ 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?XFMail.020226023229.jhb>