Benchmarking 5.4

Niall Douglas s_sourceforge at nedprod.com
Sat May 14 04:40:28 PDT 2005


As promised, here is the writeup of the benchmarking of my code on 
various systems:

http://www.nedprod.com/Tn/

The code is heavily multithreaded, with some eleven to fourteen 
threads running most of these experiencing some load. It represents a 
good test of the scheduler and thread performance. It uses its own 
mutex implementation as to be honest, my own is far faster than any 
other I've found. This could change if FreeBSD made full use of the 
M:N scope for optimisation. The code uses a mixture of process scope 
and system scope threads but mostly process scope as that's the 
default on FreeBSD builds on my library. The kernel was a GENERIC 
amd64 build but only with SCHED_ULE changed (so no witness, invariant 
etc.).

The good news is that performance now matches Linux for the first 
time having previously been a fraction. The bad news is that Windows 
is still whooping both Linux and FreeBSD.

There is a curious thing on FreeBSD - during the memory mapped i/o 
test, the percent complete goes from 0%-60% very quickly indeed but 
then hangs at 60% for what seems like ages before completing at a 
slower rate than before. What's happening internally is that a 4.47Mb 
file is being mapped in in 1Mb segments and memcpy()'ed elsewhere. I 
initially thought it might be the 4BSD scheduler so I tried ULE but 
it made no difference (to the benchmarks or anything). The test file 
was on UFS with soft updates.

Even in the packet based transfers, the percent complete noticeably 
goes faster from 0%-60% and then halts momentarily before continuing 
at a slower pace though it's nothing like as bad as memory mapped. Of 
course internally the file is still being accessed as memory mapped 
ie; the server still maps the file, just it reads and packetises it 
for the client. If I watch the disk drive light, it does flicker 
briefly at the end of the test but otherwise remained unlit - surely 
under UFS the file would still be in the cache?

If that memory mapped i/o thing were sorted out, I'm quite sure that 
FreeBSD would at least reach half the Windows speeds. Any ideas? Is 
there some kernel sysctl for setting read ahead buffering or 
something? 60% of 4.47Mb is around 2.6Mb.

Cheers,
Niall





More information about the freebsd-threads mailing list