Date: Mon, 15 Feb 1999 18:52:19 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: "John S. Dyson" <dyson@iquest.net> Cc: dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) Message-ID: <Pine.BSF.3.95.990215183646.12933M-100000@current1.whistle.com> In-Reply-To: <199902160227.VAA24443@y.dyson.net>
next in thread | previous in thread | raw e-mail | index | archive | help
John, I've been sitting on the side here for a while. You have both got good points. You have a good point that recoding without significant change is more likely to just introduce bugs and by definition is not going to improve performance. However, just as Matt should heed the suggenstions of those who are senior to him in experience, you should realise that Matt's reasons are not purely for performance. Much of the present code is almost unreadable, and sorely lacking in comments and documentation. I for one am grateful for Matt for doing ht ework of cleaning and commenting. I can follow matt's commented code a lot easier than I could before, and that means that I can now contructively comment and help. I agree that he might do well to involve more people in this, but consider John that you DID resign involvement in this code, and people, while sad to see you go, did take you at your word. If you are coming back to this then you will be welcomed with oepn arms, but you need to realise that some people find it hard sitting on their hands for 2 days waiting for an answer, and that if you are not officially involved then they will be doing so as a courtesy. I for one want you involved in discussing these changes because your experience is invaluable.. however Matt is in the stage in his life at the moment wher he has the energy of 10 raging bulls (hmm I think I'm going overboard here), so you need to make sure that that is harnessed and used constructively. It would be better if you were to take on the role of design adviser to Matt, let him take responsibility for his own decisions and give him ideas of how you would want to see things done.. My opinion is that if you outline to him all the improvements you've been envisioning, and let him do the coding, we will all come out ahead.. you will have time to do what you need to do, Matt will get to learn your experience, and FreeBSD will get well commented and dovumented code, that is readble, and designed by someone that knows what they are doing (you). You are coming across as confronatational (to me anyhow). I know you so I know that you are not being so, but you and matt need to work out a formal arangement. I know Matt is also a very reasonable guy, and since he presently has some time on his hands, I think you should make use of it to all our advantages.. All I'm saying is try work WITH him rather than just shouting "Stop Stop Be Careful!" well, that's enough lecturing to my betters for today.. :-) julian On Mon, 15 Feb 1999, John S. Dyson wrote: > John S. Dyson said: > > > > MAYBE you didn't know, but alot of communication happened behind the scenes > > regarding all of the FreeBSD VM and VFS code. Little such communication > > appears to be happening with you, and when it does, it is often one sided. > > > To follow up on this demi-mess: > I still am asking for better private communications, so that things don't > get out of hand. There are some really interesting things happening on other > fronts also, but with a focused goal of one person, it will exclude perhaps > superior solutions to certain problems. > > I want FreeBSD to succeed, and if you contribute to FreeBSD, I want your > work to succeed. Maybe what several people have been trying to do is to > get cooperation going so this thing doesn't get out of hand. Way-back-when, > FreeBSD was slightly less mission critical, and mistakes were slightly more > tolerable. The competition was just as bad as we were, and standards were > lower. FreeBSD has to be slightly more careful and slightly more structured, > because a decrease in quality will be much more disruptive than any slight > improvement. > > I applaud your *efforts* to improve the code. Work (in a physics sense) isn't > guaranteed by effort though. If there were NO resources to utilize, then > there would be no reason not to utilize them. There are resources available. > > When spearheading an effort, with a narrow and individual project, gaining > interest of other developers will be difficult. If there were no competent > people available to draw information from, then an individual project *might* > be appropriate. FreeBSD isn't in that position though. > > One reason why you might be getting public criticism, is that private criticism > hasn't been heeded. I have been lax in a few areas also, and one area where > I am quite concerned is the recoding (without sufficient redesign) that is > happening. There is mostly little algorithmic change going on, with recoding > and relabeling going on. The swap-pager, on the other hand is an improvement > (IMO), and a better platform to start from than the original code. If there > are design flaws in it, the results of correcting them has a better chance > to be correct than the original code. I claim that restructuring code, without > a *significant* performance improvement is regression. Additionally, the areas > like vm_page_alloc aren't where the CPU goes on a loaded system. To improve > system performance, you have to profile it under various conditions. You must > know that all VM code except for zeroing pages on a loaded system is almost > insignificant in the scheme of things. The place ripe for improvement is > architectural. (There might be some cases where vm_page_alloc or > vm_page_lookup are significant, but it sure sounds like the results of > artificial benchmarking to me :-)). > > The key to getting the respect of co-workers it to work WITH them, as opposed > to doing things to them. Changing code, without significantly changing > functionality is just wrong. For example, if you want to remove the object > page_hint, then remove it. Please don't recode entire routines, especially if > reverting routines to remove things like page_hint changes much of the code > back to the way it originally was. I know for a fact that code existed prior > to the page_hint stuff, but it just not might be committed. > > Both on code that I originated (if you include DG, me and certain other > contributors , we essentially rewrote the VM system, and provided the > performance that FreeBSD has today), and code that has been directly > inherited, we didn't make changes without strong cause. We even resisted > making semi-required formatting changes, because they complicate diffs. > > The ONLY reason for making gratuitious changes is to create a dependency > by alienating other developers who are used to the existing code. That > is (of course) not the conscious desire I am sure. It was my fault for not > participating in the change of vm_page_alloc, and the new code is likely > cleaner, but the disadvantage of disassociating from previous code seems > to totally overwhelm any obvious advantage at this point. > > -- > John | Never try to teach a pig to sing, > dyson@iquest.net | it makes one look stupid > jdyson@nc.com | and it irritates the pig. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.990215183646.12933M-100000>