Date: Sun, 12 Nov 1995 23:40:07 -0800 (PST) From: John Dyson <dyson> To: jehamby@lightside.com (Jake Hamby) Cc: mlh@poe.b2.org, dufault@hda.com, current@freebsd.org, freebsd-isp@freebsd.org Subject: Re: ISP state their FreeBSD concerns Message-ID: <199511130740.XAA14060@freefall.freebsd.org> In-Reply-To: <Pine.BSF.3.91.951112212901.244A@localhost> from "Jake Hamby" at Nov 12, 95 09:31:32 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Perhaps this is the reason behind the common observation that "Linux > freezes to a crawl when it starts swapping to disk." I was told this was > one big advantage of FreeBSD. Somehow, I'm starting to think that both > OS's have this problem, but perhaps this is less noticed under FreeBSD > due to: > > 1) Different paging algorithms between FreeBSD and Linux (?) > 2) More Linux users use IDE; more FreeBSD users use SCSI. > The paging algorithms on both stable versions of Linux and versions through 1.3.20 (the last one that I tested) are much slower than FreeBSD.. Also, sequential I/O is slower on EXT2FS. The problem that has been seen with FreeBSD with directory lookups is due to several items, the biggest is the limited number of vnodes that FreeBSD can cache. I am actively looking at it, quantifying the problem. The benchmarks that Joe Greco has shown us actually demonstrates a worst case clash with the name/vnode caching. It *does* represent a problem and if the files are opened in the inverse order with my new async changes, it runs MUCH faster. I am NOT belittling the problem, just trying to explain that the problem is being worked and studied. The problem with going to sleep is probably due to the 30 second sync interval and all of the modified vnodes (creation, modification, usage) times and other things like that. I have been looking at that also. John dyson@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511130740.XAA14060>