Date: Tue, 5 May 1998 00:20:20 -0500 (EST) From: "John S. Dyson" <dyson@FreeBSD.ORG> To: jak@cetlink.net (John Kelly) Cc: chat@FreeBSD.ORG Subject: Re: FreeBSD vs NetBSD Message-ID: <199805050520.AAA03775@dyson.iquest.net> In-Reply-To: <354e9927.8556243@mail.cetlink.net> from John Kelly at "May 5, 98 04:46:18 am"
next in thread | previous in thread | raw e-mail | index | archive | help
John Kelly said: > On Mon, 4 May 1998 14:01:03 -0500 (EST), "John S. Dyson" > <toor@dyson.iquest.net> wrote: > > >FreeBSD and NetBSD are both used and redistributed at NCI. NetBSD is > >the client OS (for portability), and FreeBSD is the server OS (for > >scalability and performance.) > > I read on NetBSD's web page they will soon have a new VM. I wonder > how their performance will scale then. I might have to try it out. > I have been watching their progress, and have some info. It is a long way (> 1yr) before approaching what we have. There *are* some architectural issues regarding the MACH based FreeBSD VM where there are still some challenges. Every challenge where there has been found a significant problem with the FreeBSD code has been met and solved satisfactorily. I don't think that you'll find anything out there today (including with UVM or Linux) that will outperform FreeBSD VM in real world loaded applications. Even given that, we can still gain approx 50% more performance with fork(), and if there is a speed challenge there (where it would have a real world performance impact), it can be resolved fairly quickly... (It would have been improved already, but in reality, we are down in the noise for most apps now.) I had a solution to leak problem that Chuck was talking about, and simply wasn't convinced that it was worth destabilizing the system to fix, until it was exposed. If you ever find a place where FreeBSD is slower running real apps compared with any other OS, let me know the details, and I'll work the issue. The MACH VM has some architectural advantages, and the only problem with it has been that it wasn't finished. There is a lot of steam left in our VM code, and it is nowhere near legacy, and if anything, it is way ahead of it's time. We are also getting contribution of ideas from various MACH VM experts, who have a different perspective than myself. There are some more architectural improvements forthcoming. :-). Note that the version of the VM code that I am running is significantly faster than what was in -current 5days ago (not from a LL, lmbench type measurement, but from a responsivness under load perspective.) I am still trying to figure out why it is as nice as it is. The code that I am running has better (existant) object locking and a few other new features. It will be interesting to really figure out why it is so quick. We have had some interesting features in -current, but haven't been enabled due to a lack of NEED right now, including zero copy IN/OUT of the kernel (only out is implemented right now, but in is an equivalent problem to solve, and will probably reserve that for AIO, due to API issues.) This is fairly easy to do with our relatively clean VM code, where object sharing and the like are natural capabilities. I really do think that NetBSD will be better off than they were with UVM as opposed to the orignal MACH VM code that they have been using. We knew that the code needed fixing 4yrs ago, and decided upon an evolutionary approach, rather than a revolutionary approach. If I was to do it over again, I would have had more confidence in our approach, than I did 3+yrs ago. -- John | Never try to teach a pig to sing, dyson@freebsd.org | it just makes you look stupid, jdyson@nc.com | and it irritates the pig. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805050520.AAA03775>