Date: Tue, 16 Feb 1999 20:50:42 -0500 (EST) From: "John S. Dyson" <dyson@iquest.net> To: julian@whistle.com (Julian Elischer) Cc: dyson@iquest.net, bright@cygnus.rush.net, dillon@apollo.backplane.com, freebsd-hackers@FreeBSD.ORG Subject: Re: inode / exec_map interlock ? (follow up) Message-ID: <199902170150.UAA00753@y.dyson.net> In-Reply-To: <Pine.BSF.3.95.990216161302.13983L-100000@current1.whistle.com> from Julian Elischer at "Feb 16, 99 04:14:54 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Julian Elischer said: > > > On Tue, 16 Feb 1999, John S. Dyson wrote: > > > perlsta said: > > > > > > I've noticed that the 'old' swapper or system seemed to leave a LOT of > > > swap still used en it wasn't trully needed. The new system seems to > > > reclaim these regeons as soon as they are swapped in. I've noticed the > > > new swapper is a bit more 'peppy' but i'm concerned that it is dooing what > > > John says. > > > > > Matt's code has a better allocator, and for that I applaud the code. > > Regressing behavior, when information is available and offered is not > > forward progress, but a loss of technology. You could have had the > > superior behavior of both, if the developer had listened. > > > > > > > > One other thing, I has some trouble getting to sleep last night and > > > decided to venture into src/sys/vm, the comments are VERY helpful. The > > > kind of documentation going on here will really help people get into > > > systems programming, it is MUCH appreciated. > > > > > If the code wasn't being substantially modified without review and > > agreement, I would agree. Function is more important than form, > > and function is being lost. > > Matt has agreed to go back over the changes and retrofit any changes that > are identified as being problems by you or alan or david. > He is willing to do the work if he can get a clear description of what he > needs to fix. He's also agreed to run all changes past either you or alan. > If we can get ALC to agree, I prefer him to be the first line (but I am willing to fill-in and support DG and ALC when needed.) Up until now, I can start with the existing new code, and I can help fix the missing abilities. After this, we need to move forward with a more conservative policy of defaulting to no functional changes (thereby minimizing the risk of regression.) It is likely that Matt will sometimes be able to *add* real capabilities to the code, and that is really cool. If this is agreeable, then I'll be *very* happy, and willing to participate in the background, where I feel most comfortable. FreeBSD is a legacy and needs to be treated carefully. There are things that I would have done differently than I originally did -- none of us has all of the answers, and a proper structure can make the total effectiveness more than any one member of the team. I remember working with DG, and he and I TOGETHER were much more effective than any one of us alone. Very little design happened without the other being consulted. This was very very effective, and it seems that other similar relationships should be cultivated. -- 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?199902170150.UAA00753>