Date: Mon, 15 Feb 1999 21:27:28 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: dyson@iquest.net Cc: dillon@apollo.backplane.com, dyson@iquest.net, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) Message-ID: <199902160227.VAA24443@y.dyson.net> In-Reply-To: <199902152207.RAA01900@y.dyson.net> from "John S. Dyson" at "Feb 15, 99 05:07:05 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902160227.VAA24443>