Quoting Miguel Mendez <[EMAIL PROTECTED]>: > Matthew Dillon wrote: > > > interdisciplinary people left in the project. The SMP interactions > > that John mentions are not trivial... they would challenge *ME* and > > regardless of what people think about my social mores I think most > > people would agree that I am a pretty good programmer. > > My thoughts exactly. Every time I have this kind of argument, be it on > irc or in a mailing list, I get told that Sun needed X years to do the > fine grained locks in Solaris and other similar crap. Solaris was > possible because Sun could throw more engineers at the problem if > needed. FreeBSD is not in such situation. How many people have intimate > knowledge of the VM subsystem? How many people besides John Baldwin have > ever touched the SMPng code? I don't think anybody has doubts about your > programming-fu, btw :) > One comment: I doubt that I could do the things that I used to be able on FreeBSD. However, it has been my position (for years), that the many-mutex ad-hoc approach would require brilliant people to implement, and incredibly brilliant people to maintain. (I have lost alot of context -- due to persistent burnout, but still remember alot of the problems.)
> > > serious trouble down the line. The idea (that some people have stated > > in later followups to this thread) that the APIs themselves will > > stabilize is a pipedream. The codebase may become reasonably stable, > > Agreed. Like I've said, the main problem I see is complexity. It > wouldn't matter as much if there were 5-10 people with deep knowledge of > SMPng, but with 1 or 2 hackers working on it, the chance that everything > will be ever fixed is quite small. > IMO, the easiest way to start the SMP work (from a FreeBSD monolithic approach), is to flatten as much of the VFS/VM code as possible into a continuation scheme... That is something that I could have done 5yrs ago in a few weeks, and then keep the networking system as it is. There would be shims deployed that would still support the sleep/wakeup scheme, so that the non-networking could and the new flat interface could be debugged... (It is NOT a good idea to bug the networking guys until the new scheme would be debugged.) At that point, there would be a code with explicit context carried around, and no nesting or stack context. This would have a small benefit of avoiding multiple deeply nested kernel stacks... Given the very flat scheme, each subsystem could be recoded into a message passing or simple continuation scheme (whatever is appropriate.) The system would be naturally able to be reworked -- without the hidden dependencies of the stack. VFS/VM layering problems then become resolvable. This is NOT a total solution, but should be the beginning of a thinking exercise that seems to lead into the correct direction. (Don't criticize this based upon the completeness of my prescription, but on what can eventually be developed!!!) > > IMHO ULE is making progress quite fast. I wouldn't rely on it for > production, but so far is looks very good. > The need for a new scheduler (or extreme rework on BSD) whenever you see the threads bouncing around from CPU to CPU. My temporary hack solutions couldn't work right, and it is good that the issue is being researched. > > non-interrupt threads due to priority borrowing, and non deterministic > > side effects from blocking in a mutex (because mutexes are used for > > many things now that spl's were used for before, this is a very > > serious issue). > > Yes, that's the main problem I see, not much on the scheduler side, but > on the 6-trillion-mutexes side. > The IQ of the maintainers would probably have to be 6-trillion, which would definitely allow the very few elegible developers to maintain their high priest status forever :-). > > See? I didn't mention DragonFly even once! Ooops, I didn't mention > > DFly twice. oops! Well, I didn't mention it more then twice anyway. > > Makes me wonder if some of the solutions proposed by DragonFly could be > ported to FreeBSD, but I doubt it will be done, since it's more or less > admitting that the current solution is wrong. > Sometimes, I think that people have their egos directed wrongly... The egos should be fed by the excellent behavior/performance/reliability of the FreeBSD OS. Being embarassed about appropriately borrowing code or ideas from other sources (WITH APPROPRIATE ATTRIBUTION) is counter productive. A developer should be able to say "I was wrong, or my code/design needs rework", without any problems. No-one produces the golden perfect code for the first iteration!!! Oh well -- I cannot think too much about this stuff, or I'll actually get emotionally involved again. I need to get a 'normal' job, not working at home and need to interact with people instead of CRTs. :-). (I give a sh*t about FreeBSD, and hope that WHATEVER problems that truly exist are fully resolved.) There is alot of blood sweat and tears in that codebase, and being involved in the project should be done with great respect. John _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
