I've been doing some benchmarks for RT task migrations and I stumbledover this regression. I first thought it was a regression with CFS andstarted doing a git bisect. But I later found that the "good" kernelalso failed. Then I started looking at the config options and discoveredthat SLUB has become the default.

When I put SLAB back, the regression went away, even on the lastest gittree.

So I ran the hackbench benchmarks with the latest git commit(f194d132e4971111f85c18c96067acffb13cee6d at the time of this writing).And put up the results on my web page.http://people.redhat.com/srostedt/slab/

I ran Ingo's cfs-debug-info.sh and have the results of that on the webpage. That script records lots of good information to see what kind ofmachine I ran this on. This is a 64way box (yes lots of CPUS!).

The hackbench code and the script I used to run and record the resultsis also present. I ran "hackbench 90" 20 times, 10 times as SCHED_OTHERand 10 times as SCHED_FIFO (chrt -f 10 hackbench 90). The graph showsboth runs (min, max and average). The versions that start with"rt:" (although the graph somehow truncated it to just "t:") are theSCHED_FIFO runs. (click on the graph to see a bigger version)

The regression is that hackbench slows down tremendously. It goes fromrunning just under 2 seconds to running around 14 seconds.

Hackbench seems to show this regression the most. In my tests I didn'tsee much change with kernel builds and such, but the focus was onscheduling not memory management. I'll run my kernel tests next for bothSLAB and SLUB and see if there's any difference there.

But this regression might be a reason to not have SLUB as default fornow. At least until we find out why this is affected so badly.