This is a request to backport the patch mentioned in the URL - and also incorporated into 2.6.27.5 to the prior branches of genpatches-2.6.{25,26}-base. Luminaries such as Christoph Lameter and David Miller have recently provided evidence that suggests that the kernel has been suffering from increasingly poor performance since 2.6.23 (when CFS was merged) and that, in particular, networking performance is impacted, with the most marked degradation occurring as of 2.6.25 [1] One Evgeniy Polyakov invested an immense amount of time and effort into determining what exactly might be attributable to this demonstrable loss in performance. To wit, he discovered that deficiencies in the scheduler were to blame [2]; in particular that the single worst offending commit was a7be37ac8e1565e00880531f4e2aff421a21c803 [3] which added high-resolution preemption ticks. Later on, the cause was championed by David Miller (not at his particular pleasure [4]), at which point this issue was subjected to further scrutiny. In fact, it opened up a can of worms about CFS scheduler regressions and the decline of networking performance which makes for a thread that I'd recommend to any interested reader [5]. In any case, whilst the hrticks issue has been tackled in a more desirable manner in Linus' tree, the changes were deemed too intrusive to backport to 2.6.27. Therefore, the decision was made to simply turn the feature off. The problem is that - as far as I am aware - upstream have no further interest in the 2.6.25 or 2.6.26 stable trees. Yet, I think that this is a patch that is too important to miss. I have tested it in production thus far against a hardened-sources-2.6.26-hardened-r6 kernel (with high-resolution timer and HPET support) for the scope of one working day under a high load and all is well. [1] http://lwn.net/Articles/304845/ [2] http://lwn.net/Articles/304847/ [3] http://tinyurl.com/6angh3 [4] http://lwn.net/Articles/304873/ [5] http://tinyurl.com/6y53ee PS: The wording in the patch itself could be interpreted as meaning that it is pertinent to the Sparc architecture but this is apparently not the case PPS: Although not directly related to this bug, there is an interesting off-shoot of the LKML thread [3] which hints that SLUB is not necessarily the most performant allocator (yet): http://www.gossamer-threads.com/lists/linux/kernel/991594
Oh, and I forgot to mention that hrtick has already been shown to cause other problems, including random uvesafb failures and the symptom of showing a blank screen at boot: https://bugs.launchpad.net/linux/+bug/258381 http://bugs.gentoo.org/show_bug.cgi?id=222799 ... and boot problems with Intel GMA cards: https://bugs.freedesktop.org/show_bug.cgi?id=15602 http://bugzilla.kernel.org/show_bug.cgi?id=10892 I believe hrticks was disabled in 2.6.28-rc1 and backported only to 2.6.27. I am not entirely certain the code has been reworked in Linus' tree since but, in any case, that's not relevant to what I'm asking for.
Created attachment 172297 [details, diff] 2.6.25-disable-sched_feat_hrtick.patch The patch referenced by the URL applies to 2.6.26, but not to 2.6.25. Here's a patch that works for the latter version.
Added to genpatches-2.6.26-4 and thus, gentoo-sources-2.6.26-r3.
Released in gentoo-sources-2.6.26-r3
