Hi Everyone,
This is my first post so I want to say thank you all for such an awesome distribution! It is fast, compact and customizable -- exactly what most linux hackers need. I have found some performance issues that seem to be related to process scheduling for both the redis-benchmark and some internal python testing runs. I get somewhat sporadic performance on both the redis benchmark (generally giving 90Kops/s, 60Kops/s or 30Kops/s depending on where the client and server processes land) and also internal tests (running in 5s, 3s or 1.5s sporadically).
With my internal python testing I went and compiled the latest python and numpy versions from scratch, but without improvement. With the redis benchmark I was able to fix cpu locations using taskset to get consistent 90Kops/s performance. I think this is a scheduling issue. I know this isn't ubuntu (yay!), but the same tests perform consistently well with a minimal ubuntu install (500+MB, ick!). Comparing the kernel compile options between the two and browsing through the kernel code I think it is one of the following two options (maybe both) that are not set:
CONFIG_RT_GROUP_SCHED : This is real-time group scheduling. There are several segments of the process scheduler that depend on this being set. Which includes making code run by root/kernel have rt scheduling requirements and reserving processing time for root/kernel. Having these specifications could allow more intelligent scheduling. This should probably be on for server applications and it doesn't hurt desktop performance either (99.7% free cpu on lubuntu and slitaz). The defaults leave the vast majority of processing available and it seems that the RT needs for audio/video would be improved for the desktop and reserved processing time for the system would improve servers.
CONFIG_SCHED_SMT : This is the option to enable hyperthreading. I'm not sure how this differs between the new AMD "cores" and regular Intel HT -- whether just leaving this on would affect compatibility with older CPUs or give a performance hit on non Intel CPUs. I think the scheduler identifies whether or not it should be used or it doesn't have any noticeable negative performance impact, just like SMP for old cpus without multi-core. Obviously if it breaks compatibility with old systems its a no-go, but I don't think that is the case.
When I tried to recompile my kernel there were a whole bunch of options that I didn't have a clue about and I ended up with a kernel panic. So I was wondering if anyone else has any little nagging benchmark problems? Anyone recompiled their kernel with everything the same except these two options turned on? Personally, I think these things should be turned on in the standard kernel, what do you think?
--David