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
> 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
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.
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message