| Message ID | CAE-h8tG6VCG0oX=AsPA-jKGqC=FheJD=4awByMukkUgD4uOUDg@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
Hi, Juri Lelli <juri.lelli@gmail.com> writes: > thanks a lot for your report. I was also actually experiencing something that I > think is related to your issue, but then I didn't find any time to send out > a proper patch :/. > > Could you please test what I've attached and see if it fixes your problem? Thanks for the patch, it fixes the second issue I mentioned in my previous email, i.e. the one for which I posted a patch. For this issue, FWIW: Tested-by: Vincent Legout <vincent@legout.info> Tested-by: Kevin Burns <kevinpb@vt.edu> But it doesn't seem to fix the main issue related to cpusets and SCHED_DEADLINE. It still fails if we don't come back to SCHED_OTHER before moving the task to another cpuset. I think it's due to the fact that SCHED_DEADLINE's data structures don't seem to be aware that a task migrated, they are not updated during this process. Any idea where I could have a look? Or if this is not supported, would it be possible to add some checks such that total_bw doesn't overflow when calling __dl_clear? If yes, I can try to provide a patch. Thanks! Vincent -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/02/2014 04:16 PM, Vincent Legout wrote: > Hi, > > Juri Lelli <juri.lelli@gmail.com> writes: > >> thanks a lot for your report. I was also actually experiencing something that I >> think is related to your issue, but then I didn't find any time to send out >> a proper patch :/. >> >> Could you please test what I've attached and see if it fixes your problem? > > Thanks for the patch, it fixes the second issue I mentioned in my > previous email, i.e. the one for which I posted a patch. For this issue, > FWIW: > > Tested-by: Vincent Legout <vincent@legout.info> > Tested-by: Kevin Burns <kevinpb@vt.edu> > > But it doesn't seem to fix the main issue related to cpusets and > SCHED_DEADLINE. It still fails if we don't come back to SCHED_OTHER > before moving the task to another cpuset. I think it's due to the fact > that SCHED_DEADLINE's data structures don't seem to be aware that a task > migrated, they are not updated during this process. Any idea where I > could have a look? Or if this is not supported, would it be possible to > add some checks such that total_bw doesn't overflow when calling > __dl_clear? If yes, I can try to provide a patch. I just saw this thread after sending a patch for this problem. It's not yet in the archive, though it is called: "[PATCH] sched: Reset bandwith on task when switching from SCHED_DEADLINE away" And obviously, I forgot to cc Juri. Sorry about that. cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 09/03/2014 12:00 PM, Daniel Wagner wrote: > > On 09/02/2014 04:16 PM, Vincent Legout wrote: >> Hi, >> >> Juri Lelli <juri.lelli@gmail.com> writes: >> >>> thanks a lot for your report. I was also actually experiencing something that I >>> think is related to your issue, but then I didn't find any time to send out >>> a proper patch :/. >>> >>> Could you please test what I've attached and see if it fixes your problem? >> >> Thanks for the patch, it fixes the second issue I mentioned in my >> previous email, i.e. the one for which I posted a patch. For this issue, >> FWIW: >> >> Tested-by: Vincent Legout <vincent@legout.info> >> Tested-by: Kevin Burns <kevinpb@vt.edu> >> >> But it doesn't seem to fix the main issue related to cpusets and >> SCHED_DEADLINE. It still fails if we don't come back to SCHED_OTHER >> before moving the task to another cpuset. I think it's due to the fact >> that SCHED_DEADLINE's data structures don't seem to be aware that a task >> migrated, they are not updated during this process. Any idea where I >> could have a look? Or if this is not supported, would it be possible to >> add some checks such that total_bw doesn't overflow when calling >> __dl_clear? If yes, I can try to provide a patch. > > I just saw this thread after sending a patch for this problem. It's not > yet in the archive, though it is called: > > "[PATCH] sched: Reset bandwith on task when switching from > SCHED_DEADLINE away" > > And obviously, I forgot to cc Juri. Sorry about that. After fixing my sender address it even hit the archive: https://lkml.org/lkml/2014/9/3/354 cheers, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
From 2243d25fbf0df112a83c12ca8a05e4384ea17058 Mon Sep 17 00:00:00 2001 From: Juri Lelli <juri.lelli@arm.com> Date: Wed, 11 Jun 2014 16:37:31 +0200 Subject: [PATCH] sched/deadline: clear dl_entity params when setscheduling to different class When a task is using SCHED_DEADLINE and the user setschedules it to a different class its sched_dl_entity static parameters are not cleaned up. This causes a bug if the user sets it back to SCHED_DEADLINE with the same parameters again. The problem resides in the check we perform at the very beginning of dl_overflow(): if (new_bw == p->dl.dl_bw) return 0; This condition is met in the case depicted above, so the function returns and dl_b->total_bw is not updated (the p->dl.dl_bw is not added to it). After this, admission control is broken. This patch fixes the thing, properly clearing static parameters for a task that ceases to use SCHED_DEADLINE. Reported-by: Daniele Alessandrelli <daniele.alessandrelli@gmail.com> Signed-off-by: Juri Lelli <juri.lelli@arm.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Juri Lelli <juri.lelli@gmail.com> Cc: linux-kernel@vger.kernel.org --- kernel/sched/core.c | 21 +++++++++++++++++---- 1 file changed, 17 insertions(+), 4 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index ec1a286..01738b2 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -1776,6 +1776,21 @@ int wake_up_state(struct task_struct *p, unsigned int state) } /* + * This function clears the sched_dl_entity static params. + */ +static void +__dl_clear_params(struct task_struct *p) +{ + struct sched_dl_entity *dl_se = &p->dl; + + dl_se->dl_runtime = 0; + dl_se->dl_deadline = 0; + dl_se->dl_period = 0; + dl_se->flags = 0; + dl_se->dl_bw = 0; +} + +/* * Perform scheduler related setup for a newly forked process p. * p is forked by current. * @@ -1799,10 +1814,7 @@ static void __sched_fork(unsigned long clone_flags, struct task_struct *p) RB_CLEAR_NODE(&p->dl.rb_node); hrtimer_init(&p->dl.dl_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); - p->dl.dl_runtime = p->dl.runtime = 0; - p->dl.dl_deadline = p->dl.deadline = 0; - p->dl.dl_period = 0; - p->dl.flags = 0; + __dl_clear_params(p); INIT_LIST_HEAD(&p->rt.run_list); @@ -2060,6 +2072,7 @@ static int dl_overflow(struct task_struct *p, int policy, err = 0; } else if (!dl_policy(policy) && task_has_dl_policy(p)) { __dl_clear(dl_b, p->dl.dl_bw); + __dl_clear_params(p); err = 0; } raw_spin_unlock(&dl_b->lock); -- 2.0.4