Date: Mon, 24 May 1999 13:51:54 -0500 (EST) From: Alfred Perlstein <bright@rush.net> To: Oscar Bonilla <obonilla@fisicc-ufm.edu> Cc: Orlando Andico <orly@mozcom.com>, freebsd-questions@FreeBSD.ORG Subject: Re: UFS, VM, scheduler, emulation questions Message-ID: <Pine.BSF.3.96.990524132620.9491R-100000@cygnus.rush.net> In-Reply-To: <19990524090027.B327@fisicc-ufm.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 24 May 1999, Oscar Bonilla wrote: > well, since no one has answered this one i might as well givi it a shot. > WARNING: I'm not too sure about the answers. You did a good job, i'm just going to tidy up a bit. :) > > On Mon, May 24, 1999 at 02:21:57AM +0800, Orlando Andico wrote: > > > > Hello all, > > > > I'm a new FreeBSD user, although I've used Solaris 1 and 2, IRIX 5, and > > Linux for several years and can probably consider myself an experienced > > UNIX user. I have several questions about FreeBSD implementations. > > > > 1) FreeBSD 3.x ``feels'' faster than Linux on identical hardware. Is this > > a scheduler feature (similar to Windows NT's ``boost foreground > > application performance'') or some superior kernel feature that I'm > > unaware of? > > i don't think freebsd is just "boosting" the forward application performance > in a multiuser environment there can be many forward applications depending > on how many users the system has. this isn't so in windows nt. I'm not going to pretend I know how it works exactly, but FreeBSD's scheduler tries to give new and short running processes priority until they are running for quite some time. Interactive apps get a bit of a boost, while long running application are slightly penalized, but only long running applications that are not interactive. Don't worry, freebsd won't make your emacs suddenly get unresponsive. > > 2) FreeBSD has a much faster filesystem (according to my simple tests) > > than Solaris 2.6 x86. Of course Linux still holds the record for > > filesystem writes because UFS synchronous metadata writes really slow down > > filesystem performance. What changes were done to the FreeBSD > > implementation of UFS to make this possible? is a UFS+ style metadata > > logging (journaling) feature included? > > > > 3) there is an ioctl in SunOS/Solaris to DISABLE synchronous metadata > > writes (forgot what it is though..) is this supported on FreeBSD? > > I think there's a way to disable sync metadata writes... i would check > sysctl(8). Personally I use SoftUpdates. Going to async metadata is very simple: mount -o async -u /mountpoint turning it off: mount -u /mountpoint But I agree with oscar, unless you are a specific case that violates the softupdates license, I would use it: /usr/src/sys/ufs/ffs/README.softupdates take a look in there. > > 4) does FreeBSD support LFS (large file summit) considering that UFS files > > can be >>2GB in size according to the FAQ? or is this just PR (e.g. Linux > > Reiserfs has 44-bit files, but the libc, etc, don't handle >2GB files) > > > > hmm, beats me. I've not had many chances to play with files > 2 gigs except when manipulating large tar volumes. The only problem i've had with large file is over NFS, otherwise I haven't seen anything weird. > > 5) how are pthreads implemented in FreeBSD 3.x? are these repackaged > > Provenzano's threads, ``real'' kernel threads a la Linux (Linux threads > > are processes, but fork overhead and ctx switch is very low on Linux as > > evidenced by lmbench that it doesn't matter too much), or some other form > > of userspace threads (e.g. FSU threads)? > > > > FreeBSD supports POSIX Kernel Threads (a la linux) and > pthreads (user threads). correct, the "linux threads" package is available at: http://lt.tar.com/ > > > 6) does FreeBSD retain the 4.4BSD/Mach VM system? it certainly consumes > > much less memory for buffer cache than Linux, at least the stock setup. > > When I run top(1) there is a parameter called "Wired." Is this the same as > > wired (nonpageable) memory in the SVR4 VM model? > > > > Don't know. Not really, FreeBSD has a unified VM/buffercache but does show some if its Mach and 4.4 BSD heritage. afaik wired does mean non-pageable. > > 7) if I want to recompile my kernel and system using PGCC (is this > > recommended?) which Makefiles do I alter? > > > > No, it's not recomended. FreeBSD 4.0 has egcs as the default compiler and > 3.X has gcc 2.7.2.1 as the default. From what I've heard in the mailing lists > compiling the kernel with anything but the default compiler is just a bad > idea. Actually, using pcgcc sounds interesting, you could use it, but you are entirely on your own here meaning: 1) you fix your makefiles 2) you fix other issues 3) you switch back to the system compiler when unexpected errors occur, or fix the problems yourself. > > 8) can I use DMA on IDE drives like Linux does? what sort of I/O does > > FreeBSD do on the wdc device? is it the dumb PIO that Linux does by > > default, or is MaxMultsec, etc increased to improve performance? > > > > Yes, altough it is not enabled by default. You have to add the flags > 0xa0ffa0ff in your kernel config file to each of the IDE controllers. > > > 9) how good is the SMP support in FreeBSD (vis a vis Linux [which is not > > that good, even in 2.2] and commercial OS's)? > > > > I don't think any of the opensource OS's have great SMP support. > I would give them fairly good or even usable SMP support. FreeBSD SMP is nice, it works and you get a lot of CPU utilization, I think the most important portion has been addressed, which is stability. SMP on FreeBSD has been pretty solid for almost the last year. Finer grained SMP is being worked on. > > 10) when using memfs on /tmp, is space used for files subtracted from > > swap, like in Solaris 2.x? (e.g. if I fill up /tmp with big files, the > > system won't be able to swap anymore) > > I've never used this so don't know. no, freebsd's /tmp is backed by disk, not swap, however it is entirely possible to setup what's known as a "MFS" on /tmp, but in most cases I've been told that simply keepting /tmp as a disk based filesystem and enabling softupdates make better use of memory and disk bandwidth. > > 11) I'm still keeping Linux around to run Informix Dynamic Server (as well > > as the ultra-glitzy Red Hat 6.0 GNOME desktop). Will such a complicated > > program (IDS) run under emulation? (it uses /etc/shadow instead of > > /etc/master.passwd, makes extensive use of glibc2 threads, and does many > > select(4096, ..) in there). > > Actually I've just set up informix dynamic server in my laptop under linux > emmulation, i'm accessing it through apache + php3 with the informix module > and since php needs to be linked to the informix libs i had to compile the > whole thing for linux and run everything in linux emmulation mode... ouch, my condolences... :) > > 12) how is poll() and select() implemented in the kernel? in the wake of > > the Mindcraft fiasco much attention has been given to shortcomings in the > > Linux scheduler (particularly in >2 CPU SMP boxes) and the linear scan > > necessitated by poll() and select(). How is this issue addressed in BSD? > > since wcarchive.cdrom.com handles thousands and thousands of clients, this > > issue must have come up sometime.. also, are ``wake one'' select() > > semantics implemented? what about sendfile()? > > > > Use the source luke :) It's funny how all the ranting and raving didn't make linux faster in the tests. > > 13) (my pet favorite) I like the packaging of Red Hat Linux (it's my other > > OS) but the inexplicable ``it feels faster'' performance of FreeBSD makes > > me wonder if anyone has done a ``reverse demon Penguin'' -- Linux > > userland, FreeBSD kernel. Is this even possible? > > > > everything's possible if you have source... just how much effort are you > willing to put to accomplish something is a completly different matter. I'm quite sure glibc makes assumption that the Linux kernel is the actual kernel, certainly enough hacking and you could probably get "Linux on a BSD kernel" but, why would you want to? > > 14) SGI is releasing XFS under an open-source license. Since XFS is > > implemented on top of the vnode/vfs system, conceivably all free UNIX > > variants would benefit. Is it worth it to run BSD on XFS, or is UFS > > sufficient? Running XFS would be awesome, it's a very cool filesystem. The License it's released under will pretty much dictate how FreeBSD adopts it, whether is makes it into FreeBSD's source tree and where. > > I realize these are a lot of questions, but the FAQ does not cover many of > > them. It's easier to find answers on Linux because you can browse the > > kernel mailing lists. I was hoping maybe there was a central repository > > for questions of this nature. > > you may search the mailing lists: http://www.freebsd.org/search/search.html#mailinglists good luck, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" 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.96.990524132620.9491R-100000>