On 26-Feb-02 Matthew Dillon wrote: >: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.
No, If I had one local tree I would be rather up the creek. Thankfully I have multiple trees so I can switch from one task to another without having them all tangled up in each other. :) >: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/ > > 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. My suggestion will be to back it out. I would rather not have to make said suggestion. Can you please try to fit this into the existing framework rather than ripping it all up? We need to finalize and test the design before we hardcode too many assumptions about the implementation into the interface. You have pointed out some issues with the current interface which are valid and I would like to address those, however, there are still changes to the MI implementation that need to go in once it doesn't crash right and left. If you wish I could commit the code and make current a living hell for everyone, but my ethics don't permit me to test code that I know is broken. > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> -- 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
