If we will do this i suggest to enable CONFIG_SCHEDSTATS too.
See http://cateee.net/lkddb/web-lkddb/SCHEDSTATS.html

CONFIG_SCHEDSTATS does add overhead however, and it would only really be useful for anyone testing changes to the scheduler itself.

SCHED_DEBUG adds "minimal overhead" according to Kconfig. In the scheduler, that is still more than nothing. What tunables are you seeking to modify exactly and what is the benefit?

I don't want to be a wiseacre but the dokumentation from the url above speaks from a "very slight overhead" that is why i suggest to enable both. And it says too that it is not only for testing: "These stats may be useful for both tuning and debugging the scheduler".

More informations can be found here:
http://www.ibm.com/developerworks/linux/library/l-cfs/index.html

But it is no problem to let it be. -)

SCHED_DEBUG allows, tuning of the scheduler to allow the user to tune the kernel to their needs, the default values are almost completely fair, which is nice for someone browsing emails and using the net. However you can tune the scheduler to favor essentially foreground tasks, such as multimedia tasks, IE games/3d editing/sound apps/etc.
You can also tune it for background tasks such as servers might need to stop them choking.
As for the benefit, well the ability to tune the scheduler to meet your specific needs.

An example is in the Zen line of kernels where they offer preset options at compile time, with SCHED_DEBUG you can essentially switch between those sort of options at will depending on what you are doing.

An example I personally use when using blender/games is.

kernel.sched_wakeup_granularity_ns=10000000
kernel.sched_batch_wakeup_granularity_ns=10000000
kernel.sched_min_granularity_ns=4000000
kernel.sched_latency_ns=20000000

@Daniel Nice Informations, thanks.

@devs I activate both settings in my own kernel package and my personaly summary is that CONFIG_SCHEDSTATS is not so important as it sounds in the url. I attach the output of the 3 file in /proc from my Core2Duo system to gives everybody a better overview about what is behind this informations to help for makes it easier to find a decision ("cat /proc/schedstat > proc_schedstat", "cat /proc/sched_debug" and "cat /proc/$(pidof blender)/sched").

"The default values for the tuneables are very generic and being unable to change them in the stock Arch kernel means anyone needing this option must recompile the kernel." -> Since lots of people will probably never touch those tunables, and it does add overhead to the kernel, I vote we leave this option out.

The kernel does a very good job at scheduling, so it may just be a placebo effect you're experiencing by adjusting those scheduler tunables. And the option is called DEBUG, so it's probably only meant for debugging purposes :-).

Adjusting the scheduler tunables is not a placebo, its the scheduler as you said and changing the variables has a reasonably large affect on how the system acts. Most other distros have this option enabled by default in their kernels it is not just a "DEBUG" option the CONFIG_SCHEDSTATS mentioned by Attila is the debugging end of it, the SCHED_DEBUG just puts the tuneables in sysfs to allow them to be well.. tuned.

I still don't think it's a smart idea messing with the scheduler, that's why they invented nice...

Well nice was invented a long time before CFS, so Im not quite I understand that. Nice is for adjusting priority, not for changing how the underlying scheduler acts.

It affects how much slices of CPU time the scheduler gives to that specific process. A nice value of -20 is the least nice to other processes (so it gets most CPU time), a nice value of +20 is the most nice to other processes (so it gets the least CPU time, and with this value it would only get CPU idle time).

In short, the nice value determines how much CPU time processes get relative to each other.

The scheduler tunables you're adjusting is actually how many times it allows a context switch, influencing how long a CPU time slice is, etc...

Well nice was invented a long time before CFS, so Im not quite I understand that. Nice is for adjusting priority, not for changing how the underlying scheduler acts.

Umm sorry somehow it posted the same message again. I dont think you quite understand, the sched tuneables allow you full control over the scheduler not just adjusting time slices and such you can disable/enable feature of the scheduler itself. You can control the yeild feature, in short you can tune the scheduler, setting a priority is not that same as allowing the system to decide what needs more CPU when.

Status?

Status at this moment (kernel26-2.6.30-3)

# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set

This task is opened from +1 year and +6 months without comments: closing? implement in future version?

sched_debug implemented schedstats not.