Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#16152 - [kernel26] improved scheduler behavior for desktops
Attached to Project:
Arch Linux
Opened by Pawel (kraftman) - Saturday, 12 September 2009, 09:04 GMT
Last edited by Roman Kyrylych (Romashka) - Saturday, 03 October 2009, 19:32 GMT
Opened by Pawel (kraftman) - Saturday, 12 September 2009, 09:04 GMT
Last edited by Roman Kyrylych (Romashka) - Saturday, 03 October 2009, 19:32 GMT
|
DetailsHi,
There was quite interesting discussion going on lkml about scheduler latency and performance. Ingo discovered (with some people help) there's a bug in NEW_FAIR_SLEEPERS scheduler feature which can cause visible latency for some users. It's described here: before change: http://lkml.org/lkml/2009/9/10/53 8.529265 task-clock-msecs # 0.001 CPUs 23 context-switches # 0.003 M/sec 1 CPU-migrations # 0.000 M/sec 315 page-faults # 0.037 M/sec < 11.804293482 seconds time elapsed > and after disabling NEW_FAIR_SLEEPERS: http://lkml.org/lkml/2009/9/10/229 9.009137 task-clock-msecs # 0.447 CPUs 18 context-switches # 0.002 M/sec 1 CPU-migrations # 0.000 M/sec 315 page-faults # 0.035 M/sec < 0.020167093 seconds time elapsed > AFAIK NEW_FAIR_SLEEPERS are disabled for 2.6.32, but maybe it's a good idea to have them disabled now? Rather shouldn't introduce problems. Easy way to turn them of: http://www.phoronix.com/forums/showpost.php?p=91609&postcount=40 P.S. Kudos to Nikos who reported this :> |
This task depends upon
Closed by Roman Kyrylych (Romashka)
Saturday, 03 October 2009, 19:32 GMT
Reason for closing: Deferred
Additional comments about closing: we will wait for upstream change
Saturday, 03 October 2009, 19:32 GMT
Reason for closing: Deferred
Additional comments about closing: we will wait for upstream change
As the statement says, disable it for now until the real bug is found.
Well, until it is not merged upstream i don't see a reason to add this to our kernel.