mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-25 13:43:55 +08:00
aa48380851
The idea was suggested by Peter Zijlstra here: http://marc.info/?l=linux-kernel&m=127476934517534&w=2 irq time is technically not available to the tasks running on the CPU. This patch removes irq time from CPU power piggybacking on sched_rt_avg_update(). Tested this by keeping CPU X busy with a network intensive task having 75% oa a single CPU irq processing (hard+soft) on a 4-way system. And start seven cycle soakers on the system. Without this change, there will be two tasks on each CPU. With this change, there is a single task on irq busy CPU X and remaining 7 tasks are spread around among other 3 CPUs. Signed-off-by: Venkatesh Pallipadi <venki@google.com> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> LKML-Reference: <1286237003-12406-8-git-send-email-venki@google.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
69 lines
1.7 KiB
C
69 lines
1.7 KiB
C
/*
|
|
* 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)
|
|
|
|
/*
|
|
* Place new tasks ahead so that they do not starve already running
|
|
* tasks
|
|
*/
|
|
SCHED_FEAT(START_DEBIT, 1)
|
|
|
|
/*
|
|
* Should wakeups try to preempt running tasks.
|
|
*/
|
|
SCHED_FEAT(WAKEUP_PREEMPT, 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.
|
|
*/
|
|
SCHED_FEAT(AFFINE_WAKEUPS, 1)
|
|
|
|
/*
|
|
* 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_FEAT(NEXT_BUDDY, 0)
|
|
|
|
/*
|
|
* 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.
|
|
*/
|
|
SCHED_FEAT(CACHE_HOT_BUDDY, 1)
|
|
|
|
/*
|
|
* Use arch dependent cpu power functions
|
|
*/
|
|
SCHED_FEAT(ARCH_POWER, 0)
|
|
|
|
SCHED_FEAT(HRTICK, 0)
|
|
SCHED_FEAT(DOUBLE_TICK, 0)
|
|
SCHED_FEAT(LB_BIAS, 1)
|
|
SCHED_FEAT(LB_SHARES_UPDATE, 1)
|
|
SCHED_FEAT(ASYM_EFF_LOAD, 1)
|
|
|
|
/*
|
|
* 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.
|
|
*/
|
|
SCHED_FEAT(OWNER_SPIN, 1)
|
|
|
|
/*
|
|
* Decrement CPU power based on irq activity
|
|
*/
|
|
SCHED_FEAT(NONIRQ_POWER, 1)
|