|
:: Quote :: But a question, if you require this much control, what is stopping you from creating your own kernel? Most people would build their own kernel if they require special tuning for their unique tasks.Well, tuning the maintainer instead might work, too. Back to top |
|||||
|
Those values have effect, not while SCHED_DEBUG is enabled. If there was not a performance issue, I would not have increased the target latency (someone noticed that on their configuration 16ms introduced noticeable lag and I confirmed this with an older laptop of mine).
If you review the patch of zen-tune, you'll see things like this: :: Code :: diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index ba7fd6e..10fa62a 100644 (file) --- a/kernel/sched_fair.c +++ b/kernel/sched_fair.c @@ -34,18 +34,22 @@ * (to see the precise effective timeslice length of your workload, * run vmstat and monitor the context-switches (cs) field) */ -unsigned int sysctl_sched_latency = 20000000ULL; + +unsigned int sysctl_sched_latency; +EXPORT_SYMBOL(sysctl_sched_latency); /* * Minimal preemption granularity for CPU-bound tasks: * (default: 4 msec * (1 + ilog(ncpus)), units: nanoseconds) */ -unsigned int sysctl_sched_min_granularity = 4000000ULL; +unsigned int sysctl_sched_min_granularity; +EXPORT_SYMBOL(sysctl_sched_min_granularity); /* * is kept at sysctl_sched_latency / sysctl_sched_min_granularity */ -static unsigned int sched_nr_latency = 5; +unsigned int sched_nr_latency; +EXPORT_SYMBOL(sched_nr_latency); /* * After fork, child runs first. (default) If set to 0 then @@ -69,7 +73,8 @@ unsigned int __read_mostly sysctl_sched_compat_yield; * and reduces their over-scheduling. Synchronous workloads will still * have immediate wakeup/sleep latencies. */ -unsigned int sysctl_sched_wakeup_granularity = 5000000UL; +unsigned int sysctl_sched_wakeup_granularity; +EXPORT_SYMBOL(sysctl_sched_wakeup_granularity); const_debug unsigned int sysctl_sched_migration_cost = 500000UL; when CONFIG_SCHED_DEBUG is enabled, none of these values are used at all. Instead, non-preemptive values are used instead, such as 8000000ns for wakeup granularity and 40000000ns for the target latency. So no, until these defaults are changed, I'm not reenabling CONFIG_SCHED_DEBUG. :: Quote :: Well, tuning the maintainer instead might work, too.If you want to continue being destructive, join #smxi on irc.oftc.net. Back to top |
|||||
|
Thanks for speaking with me on #smxi, the following has occurred due to our discussion.
Reverted zen-tune commit in zen sources Enabled CONFIG_SCHED_DEBUG Set static values for scheduler latency to the following -> target latency = 10ms -> minimum preemption latency = 2ms -> wakeup granularity latency = 3ms Back to top |
|||||
|
All times are GMT - 8 Hours
|
|||||