Below is the video of the Linux desktop when running the Linux Git kernel and the patch in question was applied but the auto-group scheduler was disabled via its sysfs interface.
As you can see, the experience when compiling the Linux kernel with so many jobs is rather troubling to the Linux desktop experience. At no point in the video was the 1080p sample video paused, but that was just where the current mainline Linux kernel is at with 2.6.37. There was also some stuttering with glxgears and some responsiveness elsewhere. This is even with all of the Linux 2.6.37 kernel improvements up to today. If recording a video of an older kernel release, the experience is even more horrific! Now let's see what happens when enabling the patch's new scheduler code.
It is truly a night and day difference. The 1080p Ogg video now played smoothly a majority of the time when still compiling the Linux kernel with 64 jobs. Glxgears was also better and the window movements and desktop interactivity was far better. When compiling the Linux kernel with 128 jobs or other workloads that apply even greater strain, the results are even more dramatic, but it is not great for a video demonstration; the first video recorded under greater strained made the "before look" appear as like a still photograph.
This patch truly does wonders to the Linux kernel in improving the desktop responsiveness / interactivity. This patch with improving his web-browsing experience and more, impresses even Linus Torvalds. The merge window is now closed for the Linux 2.6.37 kernel, but this should be an exciting improvement that should be found in the Linux 2.6.38 kernel and at least keep the people happy waiting around for Reiser4 / Open-Source VIA Graphics / Radeon HD 6000 Series DRM to arrive in the mainline kernel.
In related work while waiting for your kernel to build, you may be interested in reading the recent five years of Linux kernel benchmarks and GCC vs. LLVM compiler benchmarks with GCC 4.2/4.3/4.4/4.5/4.6, LLVM-GCC, Clang on LLVM 2.8, and DragonEgg on LLVM 2.8 with GCC 4.5.1.