Hi guys, For a while now I have been interested in the alternative ideas about SMP serialization and concurrency that are being pursued by the dragonfly project, so I thought it would be interesting to see how they have played out over the past 4 years of development.
One problem I ran into is that dragonfly is not able to boot on many recent (particularly AMD) systems that I tried, because they require ACPI for PCI bus enumeration and the older FreeBSD 4.x-derived code base does not do this. Finally I did find an Intel 8-core system that is able to run Dragonfly. The 1.9 kernel I first tried hung during boot, but 1.8 boots successfully. I recompiled the kernel for SMP and disabled INVARIANTS and the I[345]86_CPU options. /etc/malloc.conf was set to aj. These seemed to be the only obvious tuning options I could find, but perhaps I missed something. The benchmark I ran was the sysbench SQL database benchmark in read-only mode, which seems to be a good SMP test case. I ran it against mysql 5.0.37 with some config file tuning (I can go into details if required). The system has 4GB of RAM (actually 8GB, but the rest is ignored on i386 without PAE), so the database fits in memory and no disks are accessed after the initial warmup run. I compared Dragonfly 1.8 with both the libc_r and libthread_xu thread libraries to FreeBSD 7.0 on the same hardware. I was somewhat surprised by the results: http://obsecurity.dyndns.org/dfly.png The libc_r result is to be expected: a userland threading library will not give any scaling improvements as the client workload increases. The slight peaks at higher loads are probably just random variation. However I was surprised at the libthread_xu results. There is a very small performance increase up to 3 clients, but the peak performance is only about 30% higher than the baseline. I confirmed that SMP is active and processes are being scheduled on all 8 CPUs, but the system is basically never performing more than ~1.3 CPU's of work. Can anyone suggest what might be wrong? Kris
