blob: 294e10edd3c8bc67e135cce272c772e9ca67379e [file] [log] [blame]
Peter Zijlstrae26af0e2009-09-11 12:31:23 +02001/*
2 * Disregards a certain amount of sleep time (sched_latency_ns) and
3 * considers the task to be running during that period. This gives it
4 * a service deficit on wakeup, allowing it to run sooner.
5 */
Ingo Molnar3f2aa302009-09-10 20:34:48 +02006SCHED_FEAT(NEW_FAIR_SLEEPERS, 0)
Peter Zijlstrae26af0e2009-09-11 12:31:23 +02007
8/*
9 * By not normalizing the sleep time, heavy tasks get an effective
10 * longer period, and lighter task an effective shorter period they
11 * are considered running.
12 */
Peter Zijlstrae52fb7c2009-01-14 12:39:19 +010013SCHED_FEAT(NORMALIZED_SLEEPER, 0)
Peter Zijlstrae26af0e2009-09-11 12:31:23 +020014
15/*
16 * Place new tasks ahead so that they do not starve already running
17 * tasks
18 */
Peter Zijlstraf00b45c2008-04-19 19:45:00 +020019SCHED_FEAT(START_DEBIT, 1)
Peter Zijlstrae26af0e2009-09-11 12:31:23 +020020
21/*
22 * Should wakeups try to preempt running tasks.
23 */
24SCHED_FEAT(WAKEUP_PREEMPT, 1)
25
26/*
27 * Compute wakeup_gran based on task behaviour, clipped to
28 * [0, sched_wakeup_gran_ns]
29 */
30SCHED_FEAT(ADAPTIVE_GRAN, 1)
31
32/*
33 * When converting the wakeup granularity to virtual time, do it such
34 * that heavier tasks preempting a lighter task have an edge.
35 */
36SCHED_FEAT(ASYM_GRAN, 1)
37
38/*
39 * Always wakeup-preempt SYNC wakeups, see SYNC_WAKEUPS.
40 */
41SCHED_FEAT(WAKEUP_SYNC, 0)
42
43/*
44 * Wakeup preempt based on task behaviour. Tasks that do not overlap
45 * don't get preempted.
46 */
47SCHED_FEAT(WAKEUP_OVERLAP, 0)
48
49/*
50 * Use the SYNC wakeup hint, pipes and the likes use this to indicate
51 * the remote end is likely to consume the data we just wrote, and
52 * therefore has cache benefit from being placed on the same cpu, see
53 * also AFFINE_WAKEUPS.
54 */
Peter Zijlstraf00b45c2008-04-19 19:45:00 +020055SCHED_FEAT(SYNC_WAKEUPS, 1)
Peter Zijlstrae26af0e2009-09-11 12:31:23 +020056
57/*
58 * Based on load and program behaviour, see if it makes sense to place
59 * a newly woken task on the same cpu as the task that woke it --
60 * improve cache locality. Typically used with SYNC wakeups as
61 * generated by pipes and the like, see also SYNC_WAKEUPS.
62 */
63SCHED_FEAT(AFFINE_WAKEUPS, 1)
64
65/*
66 * Prefer to schedule the task we woke last (assuming it failed
67 * wakeup-preemption), since its likely going to consume data we
68 * touched, increases cache locality.
69 */
Mike Galbraith0ec9fab2009-09-15 15:07:03 +020070SCHED_FEAT(NEXT_BUDDY, 0)
Peter Zijlstrae26af0e2009-09-11 12:31:23 +020071
72/*
73 * Prefer to schedule the task that ran last (when we did
74 * wake-preempt) as that likely will touch the same data, increases
75 * cache locality.
76 */
77SCHED_FEAT(LAST_BUDDY, 1)
78
79/*
80 * Consider buddies to be cache hot, decreases the likelyness of a
81 * cache buddy being migrated away, increases cache locality.
82 */
83SCHED_FEAT(CACHE_HOT_BUDDY, 1)
84
Peter Zijlstra8e6598a2009-09-03 13:20:03 +020085/*
86 * Use arch dependent cpu power functions
87 */
88SCHED_FEAT(ARCH_POWER, 0)
89
Ingo Molnar0c4b83d2008-10-20 14:27:43 +020090SCHED_FEAT(HRTICK, 0)
Peter Zijlstraf00b45c2008-04-19 19:45:00 +020091SCHED_FEAT(DOUBLE_TICK, 0)
Peter Zijlstraefc2dea2008-08-20 12:44:55 +020092SCHED_FEAT(LB_BIAS, 1)
Peter Zijlstra2398f2c2008-06-27 13:41:35 +020093SCHED_FEAT(LB_WAKEUP_UPDATE, 1)
Peter Zijlstraf5bfb7d2008-06-27 13:41:39 +020094SCHED_FEAT(ASYM_EFF_LOAD, 1)
Peter Zijlstrae26af0e2009-09-11 12:31:23 +020095
96/*
97 * Spin-wait on mutex acquisition when the mutex owner is running on
98 * another cpu -- assumes that when the owner is running, it will soon
99 * release the lock. Decreases scheduling overhead.
100 */
Peter Zijlstra0d66bf62009-01-12 14:01:47 +0100101SCHED_FEAT(OWNER_SPIN, 1)