2009-09-11 14:31:23 +04:00
|
|
|
/*
|
|
|
|
* Disregards a certain amount of sleep time (sched_latency_ns) and
|
|
|
|
* considers the task to be running during that period. This gives it
|
|
|
|
* a service deficit on wakeup, allowing it to run sooner.
|
|
|
|
*/
|
2009-09-16 10:54:45 +04:00
|
|
|
SCHED_FEAT(FAIR_SLEEPERS, 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Only give sleepers 50% of their service deficit. This allows
|
|
|
|
* them to run sooner, but does not allow tons of sleepers to
|
|
|
|
* rip the spread apart.
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(GENTLE_FAIR_SLEEPERS, 1)
|
2009-09-11 14:31:23 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* By not normalizing the sleep time, heavy tasks get an effective
|
|
|
|
* longer period, and lighter task an effective shorter period they
|
|
|
|
* are considered running.
|
|
|
|
*/
|
2009-01-14 14:39:19 +03:00
|
|
|
SCHED_FEAT(NORMALIZED_SLEEPER, 0)
|
2009-09-11 14:31:23 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Place new tasks ahead so that they do not starve already running
|
|
|
|
* tasks
|
|
|
|
*/
|
2008-04-19 21:45:00 +04:00
|
|
|
SCHED_FEAT(START_DEBIT, 1)
|
2009-09-11 14:31:23 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Should wakeups try to preempt running tasks.
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(WAKEUP_PREEMPT, 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Compute wakeup_gran based on task behaviour, clipped to
|
|
|
|
* [0, sched_wakeup_gran_ns]
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(ADAPTIVE_GRAN, 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* When converting the wakeup granularity to virtual time, do it such
|
|
|
|
* that heavier tasks preempting a lighter task have an edge.
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(ASYM_GRAN, 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Always wakeup-preempt SYNC wakeups, see SYNC_WAKEUPS.
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(WAKEUP_SYNC, 0)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Wakeup preempt based on task behaviour. Tasks that do not overlap
|
|
|
|
* don't get preempted.
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(WAKEUP_OVERLAP, 0)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Use the SYNC wakeup hint, pipes and the likes use this to indicate
|
|
|
|
* the remote end is likely to consume the data we just wrote, and
|
|
|
|
* therefore has cache benefit from being placed on the same cpu, see
|
|
|
|
* also AFFINE_WAKEUPS.
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(SYNC_WAKEUPS, 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Based on load and program behaviour, see if it makes sense to place
|
|
|
|
* a newly woken task on the same cpu as the task that woke it --
|
|
|
|
* improve cache locality. Typically used with SYNC wakeups as
|
|
|
|
* generated by pipes and the like, see also SYNC_WAKEUPS.
|
|
|
|
*/
|
2008-04-19 21:45:00 +04:00
|
|
|
SCHED_FEAT(AFFINE_WAKEUPS, 1)
|
2009-09-11 14:31:23 +04:00
|
|
|
|
2009-09-15 21:38:52 +04:00
|
|
|
/*
|
|
|
|
* Weaken SYNC hint based on overlap
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(SYNC_LESS, 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add SYNC hint based on overlap
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(SYNC_MORE, 0)
|
|
|
|
|
2009-09-11 14:31:23 +04:00
|
|
|
/*
|
|
|
|
* Prefer to schedule the task we woke last (assuming it failed
|
|
|
|
* wakeup-preemption), since its likely going to consume data we
|
|
|
|
* touched, increases cache locality.
|
|
|
|
*/
|
sched: Improve latencies and throughput
Make the idle balancer more agressive, to improve a
x264 encoding workload provided by Jason Garrett-Glaser:
NEXT_BUDDY NO_LB_BIAS
encoded 600 frames, 252.82 fps, 22096.60 kb/s
encoded 600 frames, 250.69 fps, 22096.60 kb/s
encoded 600 frames, 245.76 fps, 22096.60 kb/s
NO_NEXT_BUDDY LB_BIAS
encoded 600 frames, 344.44 fps, 22096.60 kb/s
encoded 600 frames, 346.66 fps, 22096.60 kb/s
encoded 600 frames, 352.59 fps, 22096.60 kb/s
NO_NEXT_BUDDY NO_LB_BIAS
encoded 600 frames, 425.75 fps, 22096.60 kb/s
encoded 600 frames, 425.45 fps, 22096.60 kb/s
encoded 600 frames, 422.49 fps, 22096.60 kb/s
Peter pointed out that this is better done via newidle_idx,
not via LB_BIAS, newidle balancing should look for where
there is load _now_, not where there was load 2 ticks ago.
Worst-case latencies are improved as well as no buddies
means less vruntime spread. (as per prior lkml discussions)
This change improves kbuild-peak parallelism as well.
Reported-by: Jason Garrett-Glaser <darkshikari@gmail.com>
Signed-off-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
LKML-Reference: <1253011667.9128.16.camel@marge.simson.net>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2009-09-15 17:07:03 +04:00
|
|
|
SCHED_FEAT(NEXT_BUDDY, 0)
|
2009-09-11 14:31:23 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Prefer to schedule the task that ran last (when we did
|
|
|
|
* wake-preempt) as that likely will touch the same data, increases
|
|
|
|
* cache locality.
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(LAST_BUDDY, 1)
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Consider buddies to be cache hot, decreases the likelyness of a
|
|
|
|
* cache buddy being migrated away, increases cache locality.
|
|
|
|
*/
|
2008-04-19 21:45:00 +04:00
|
|
|
SCHED_FEAT(CACHE_HOT_BUDDY, 1)
|
2009-09-11 14:31:23 +04:00
|
|
|
|
2009-09-03 15:20:03 +04:00
|
|
|
/*
|
|
|
|
* Use arch dependent cpu power functions
|
|
|
|
*/
|
|
|
|
SCHED_FEAT(ARCH_POWER, 0)
|
|
|
|
|
2008-10-20 16:27:43 +04:00
|
|
|
SCHED_FEAT(HRTICK, 0)
|
2008-04-19 21:45:00 +04:00
|
|
|
SCHED_FEAT(DOUBLE_TICK, 0)
|
2008-08-20 14:44:55 +04:00
|
|
|
SCHED_FEAT(LB_BIAS, 1)
|
2009-09-16 15:44:33 +04:00
|
|
|
SCHED_FEAT(LB_SHARES_UPDATE, 1)
|
2008-06-27 15:41:39 +04:00
|
|
|
SCHED_FEAT(ASYM_EFF_LOAD, 1)
|
2009-09-11 14:31:23 +04:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Spin-wait on mutex acquisition when the mutex owner is running on
|
|
|
|
* another cpu -- assumes that when the owner is running, it will soon
|
|
|
|
* release the lock. Decreases scheduling overhead.
|
|
|
|
*/
|
2009-01-12 16:01:47 +03:00
|
|
|
SCHED_FEAT(OWNER_SPIN, 1)
|