Date: Fri, 24 Oct 2003 15:27:43 -0700 From: Sean Chittenden <sean@chittenden.org> To: Felix von Leitner <felix-benchmark@fefe.de> Cc: freebsd-performance@freebsd.org Subject: Re: Please help me tune FreeBSD for bulk.fefe.de/scalability/ Message-ID: <20031024222743.GC13386@perrin.nxad.com> In-Reply-To: <20031024142345.GA9997@codeblau.de> References: <20031024142345.GA9997@codeblau.de>
next in thread | previous in thread | raw e-mail | index | archive | help
> Please also tell me if you have suggestions for other benchmarks > that say something about the scalability of an operating system, > that I could (and should) include in my benchmark suite. >From a database perspective, I have two benchmarks that I'd be interested in seeing. 1) Time required to read a frequently accessed page that has been mmap()'ed. As you state, it takes FreeBSD longer to mmap() the first page, but I'd like to see the benefit for the startup time documented in a benchmark. Presumably, the extra time required to load the first page is worth something. 2) Time required to read a frequently accessed page that has not been mmap()'ed (ie, raw read() IO). I'd like to know how fast each OS's file system cache is. A few other comments about your benchmarking (which are really great to have, thank you!): 1) Are you using the most recent version of FreeBSD-CURRENT? If so, I'd be curious to have libpthreads/libkse benchmarked. Time to spawn a new thread and time required to join ten threads. Something like that would be quasi-useful. 2) You state in your mmap benchmark section: "As you can see, Linux 2.4 appears to scale O(n), while Linux 2.6 is O(1). FreeBSD looks to be much faster than Linux 2.6, but you need to keep in mind that FreeBSD took an extraordinary time to do the actual mmap, so this good result does not save the day for FreeBSD." I would disagree in that it is the common case for an mmap()'ed page to be simultaneously mmap()'ed by other processes (think Apache serving a busy homepage: each proc is mmap()'ing the same file). I'd imagine that FreeBSD would win in a performance test of this nature because of the work it did when it mmap()'ed the first page, therefore think that this proves that FreeBSD is justified in the extra time that it takes when mmap()'ing a new page. 3) FreeBSD isn't finished in terms of its locking. That said, these benchmarks really impress me that even though many subsystems are still under the Giant lock, FreeBSD 5.X performs as well, if not better than Linux 2.6. -sc -- Sean Chittenden
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031024222743.GC13386>