2
0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-11-18 07:35:12 +08:00

sched: Kill WAKEUP_PREEMPT

Remove the WAKEUP_PREEMPT feature, disabling it doesn't make any sense
and its outlived its use by a long long while.

Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Acked-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20110729082033.GB12106@zhy
Signed-off-by: Ingo Molnar <mingo@elte.hu>
This commit is contained in:
Yong Zhang 2011-07-29 16:20:33 +08:00 committed by Ingo Molnar
parent e2b245f89e
commit 2c2efaed9b
2 changed files with 1 additions and 13 deletions

View File

@ -1095,9 +1095,6 @@ check_preempt_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr)
* narrow margin doesn't have to wait for a full slice. * narrow margin doesn't have to wait for a full slice.
* This also mitigates buddy induced latencies under load. * This also mitigates buddy induced latencies under load.
*/ */
if (!sched_feat(WAKEUP_PREEMPT))
return;
if (delta_exec < sysctl_sched_min_granularity) if (delta_exec < sysctl_sched_min_granularity)
return; return;
@ -1233,7 +1230,7 @@ entity_tick(struct cfs_rq *cfs_rq, struct sched_entity *curr, int queued)
return; return;
#endif #endif
if (cfs_rq->nr_running > 1 || !sched_feat(WAKEUP_PREEMPT)) if (cfs_rq->nr_running > 1)
check_preempt_tick(cfs_rq, curr); check_preempt_tick(cfs_rq, curr);
} }
@ -1899,10 +1896,6 @@ static void check_preempt_wakeup(struct rq *rq, struct task_struct *p, int wake_
if (unlikely(p->policy != SCHED_NORMAL)) if (unlikely(p->policy != SCHED_NORMAL))
return; return;
if (!sched_feat(WAKEUP_PREEMPT))
return;
find_matching_se(&se, &pse); find_matching_se(&se, &pse);
update_curr(cfs_rq_of(se)); update_curr(cfs_rq_of(se));
BUG_ON(!pse); BUG_ON(!pse);

View File

@ -11,11 +11,6 @@ SCHED_FEAT(GENTLE_FAIR_SLEEPERS, 1)
*/ */
SCHED_FEAT(START_DEBIT, 1) 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 * 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 -- * a newly woken task on the same cpu as the task that woke it --