Messages in this thread | | | Subject | Re: [PATCH 5/5] sched/deadline: Use return value of SCHED_WARN_ON() in bw accounting | From | Dietmar Eggemann <> | Date | Tue, 30 Jul 2019 17:08:35 +0100 |
| |
On 7/30/19 9:23 AM, Peter Zijlstra wrote: > On Mon, Jul 29, 2019 at 05:59:04PM +0100, Dietmar Eggemann wrote: >> On 7/29/19 5:54 PM, Peter Zijlstra wrote: >>> On Fri, Jul 26, 2019 at 12:18:19PM +0200, luca abeni wrote: >>>> Hi Dietmar, >>>> >>>> On Fri, 26 Jul 2019 09:27:56 +0100 >>>> Dietmar Eggemann <dietmar.eggemann@arm.com> wrote: >>>> >>>>> To make the decision whether to set rq or running bw to 0 in underflow >>>>> case use the return value of SCHED_WARN_ON() rather than an extra if >>>>> condition. >>>> >>>> I think I tried this at some point, but if I remember well this >>>> solution does not work correctly when SCHED_DEBUG is not enabled. >>> >>> Well, it 'works' in so far that it compiles. But it might not be what >>> one expects. That is, for !SCHED_DEBUG the return value is an >>> unconditional false. >>> >>> In this case I think that's fine, the WARN _should_ not be happending. >> >> But there is commit 6d3aed3d ("sched/debug: Fix SCHED_WARN_ON() to >> return a value on !CONFIG_SCHED_DEBUG as well")? >> >> But it doesn't work with !CONFIG_SCHED_DEBUG >> >> What compiles and work is (at least on Arm64). >> >> diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h >> index 4012f98b9d26..494a767a4091 100644 >> --- a/kernel/sched/sched.h >> +++ b/kernel/sched/sched.h >> @@ -78,7 +78,7 @@ >> #ifdef CONFIG_SCHED_DEBUG >> # define SCHED_WARN_ON(x) WARN_ONCE(x, #x) >> #else >> -# define SCHED_WARN_ON(x) ({ (void)(x), 0; }) >> +# define SCHED_WARN_ON(x) ({ (void)(x), x; }) > > Why doesn't the ,0 compile? That should work just fine. The thing is, > the two existing users: > > kernel/sched/fair.c: if (SCHED_WARN_ON(!se->on_rq)) > kernel/sched/fair.c: if (SCHED_WARN_ON(!se->on_rq)) > > seem to compile just fine with it.
You're right, compiling is not an issue. But it looks like the code does different things depending on CONFIG_SCHED_DEBUG.
E.g. in set_last_buddy() we would return if '!se->on_rq' with CONFIG_SCHED_DEBUG and continue the for_each_sched_entity() with !CONFIG_SCHED_DEBUG.
IMHO, this forced Luca e.g. in __sub_running_bw() to code:
SCHED_WARN_ON(dl_rq->running_bw > old); if (dl_rq->running_bw > old) dl_rq->running_bw = 0;
and not:
if (SCHED_WARN_ON(dl_rq->running_bw > old)) dl_rq->running_bw = 0;
I experimented with '# define SCHED_WARN_ON(x) ({ (void)(x), x; })' and in this case code inside an 'if (SCHED_WARN_ON(cond))' is also executed with !CONFIG_SCHED_DEBUG.
| |