Re: [PATCH v6 1/7] sched/deadline: fix start high-res preemption tick for a non-leftmost task

[Wanpeng Li]

Replace the subject by "Subject: [PATCH v6 2/7] sched/deadline: fix rt runtime corrupt when dl refuse a smaller bandwidth"
On Wed, Nov 26, 2014 at 08:44:02AM +0800, Wanpeng Li wrote:
>Dl class will refuse the bandwidth being set to some value smaller
>than the currently allocated bandwidth in any of the root_domains
>through sched_rt_runtime_us and sched_rt_period_us. RT runtime will
>be set according to sched_rt_runtime_us before dl class verify if
>the new bandwidth is suitable in the case of !CONFIG_RT_GROUP_SCHED.
>
>However, rt runtime will be corrupt if dl refuse the new bandwidth
>since there is no undo to reset the rt runtime to the old value.
>
>This patch fix it by verifying new bandwidth for deadline in advance.
>
>Cc: Juri Lelli <juri.lelli@xxxxxxx>
>Signed-off-by: Wanpeng Li <wanpeng.li@xxxxxxxxxxxxxxx>
>---
>v1 -> v2:
> * move sched_dl_global_constraints before sched_rt_global_constraints,
>   and change the name of the former to sched_dl_global_validate().
>
> kernel/sched/core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/kernel/sched/core.c b/kernel/sched/core.c
>index 603c462..981f075 100644
>--- a/kernel/sched/core.c
>+++ b/kernel/sched/core.c
>@@ -7808,7 +7808,7 @@ static int sched_rt_global_constraints(void)
> }
> #endif /* CONFIG_RT_GROUP_SCHED */
> 
>-static int sched_dl_global_constraints(void)
>+static int sched_dl_global_validate(void)
> {
> 	u64 runtime = global_rt_runtime();
> 	u64 period = global_rt_period();
>@@ -7909,11 +7909,11 @@ int sched_rt_handler(struct ctl_table *table, int write,
> 		if (ret)
> 			goto undo;
> 
>-		ret = sched_rt_global_constraints();
>+		ret = sched_dl_global_validate();
> 		if (ret)
> 			goto undo;
> 
>-		ret = sched_dl_global_constraints();
>+		ret = sched_rt_global_constraints();
> 		if (ret)
> 			goto undo;
> 
>-- 
>1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/