From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1753745AbcITW7K (ORCPT <rfc822;w@1wt.eu>);
        Tue, 20 Sep 2016 18:59:10 -0400
Received: from Galois.linutronix.de ([146.0.238.70]:60817 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752961AbcITW7J (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 20 Sep 2016 18:59:09 -0400
Date: Wed, 21 Sep 2016 00:56:32 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
cc: Julien Desfossez <jdesfossez@efficios.com>,
        Peter Zijlstra <peterz@infradead.org>, rostedt <rostedt@goodmis.org>,
        Ingo Molnar <mingo@redhat.com>, daolivei <daolivei@redhat.com>,
        linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [RFC PATCH 1/6] sched/fair: check_preempt_wakeup: Fix assumption
 on the default policy
In-Reply-To: <342487362.26930.1474409041257.JavaMail.zimbra@efficios.com>
Message-ID: <alpine.DEB.2.20.1609210042330.5476@nanos>
References: <1474060148-13171-1-git-send-email-jdesfossez@efficios.com> <alpine.DEB.2.20.1609202236430.5476@nanos> <342487362.26930.1474409041257.JavaMail.zimbra@efficios.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Tue, 20 Sep 2016, Mathieu Desnoyers wrote:
> So what is then puzzling us is this:
> 
> rt_mutex_setprio()
> 
>         if (dl_prio(prio)) {
>                 struct task_struct *pi_task = rt_mutex_get_top_task(p);
>                 if (!dl_prio(p->normal_prio) ||
>                     (pi_task && dl_entity_preempt(&pi_task->dl, &p->dl))) {
>                         p->dl.dl_boosted = 1;
>                         queue_flag |= ENQUEUE_REPLENISH;
>                 } else
>                         p->dl.dl_boosted = 0;
>                 p->sched_class = &dl_sched_class;
>         } else if (rt_prio(prio)) {
>                 if (dl_prio(oldprio))
>                         p->dl.dl_boosted = 0;
>                 if (oldprio < prio)
>                         queue_flag |= ENQUEUE_HEAD;
>                 p->sched_class = &rt_sched_class;
>         } else {
>                 if (dl_prio(oldprio))
>                         p->dl.dl_boosted = 0;
>                 if (rt_prio(oldprio))
>                         p->rt.timeout = 0;
>                 p->sched_class = &fair_sched_class;
>         }
> 
> So in the 3rd block, this is the case where we inherit a
> new prio which is neither LD nor RT, so it's "fair".
> 
> If we try to assign a fair prio to a task of DL or RT
> prio, the dl_boosted is set to 0, or the rt timeout is
> set to 0. However, we do change the sched_class of the
> target task to &fair_sched_class.
> 
> This code path seems to imply that a RT or DL task can
> change sched_class to "fair". Indeed, it makes no sense,
> so I have the feeling we're missing something important
> here.

Yes. Look at the call site of this. This is called in two cases:

 - The task blocked on a lock pushes the task owning the lock and in that
   case it is guaranteed that the blocked task is in the same or in a
   higher scheduling class. We have no support for inverse PI (yet).

 - The task which got boosted deboosts itself after releasing the lock. In
   that case it falls back to its original class/priority/bandwidth.

Hope that helps.

> >> Cc: Peter Zijlstra <peterz@infradead.org>
> >> Cc: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
> >> Cc: Thomas Gleixner <tglx@linutronix.de>
> >> Cc: Ingo Molnar <mingo@redhat.com>
> >> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> >> Signed-off-by: Julien Desfossez <jdesfossez@efficios.com>
> > 
> > Who wrote the patch?
> 
> Julien is the author.

So the SOB chain is wrong because you neither authored the patch nor you
conveyed it.

Thanks,

	tglx