All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Juri Lelli <juri.lelli@arm.com>
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Steven Rostedt <rostedt@goodmis.org>,
	Juri Lelli <juri.lelli@gmail.com>,
	Andrea Parri <parri.andrea@gmail.com>
Subject: Re: [PATCH] sched: Fix PI handling vs sched_setscheduler()
Date: Wed, 20 Jan 2016 11:24:26 +0100	[thread overview]
Message-ID: <20160120102425.GI6357@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <20160120100839.GL8573@e106622-lin>

On Wed, Jan 20, 2016 at 10:08:39AM +0000, Juri Lelli wrote:
> Hi,
> 
> On 19/01/16 12:18, Peter Zijlstra wrote:
> 
> [...]
> 
> > @@ -4097,15 +4099,14 @@ static int __sched_setscheduler(struct t
> >  	if (running)
> >  		p->sched_class->set_curr_task(rq);
> >  	if (queued) {
> > -		int enqueue_flags = ENQUEUE_RESTORE;
> >  		/*
> >  		 * We enqueue to tail when the priority of a task is
> >  		 * increased (user space view).
> >  		 */
> > -		if (oldprio <= p->prio)
> > -			enqueue_flags |= ENQUEUE_HEAD;
> > +		if (oldprio < p->prio)
> > +			queue_flags |= ENQUEUE_HEAD;
> 
> Was this condition broken before or it needs to be changed now with this
> patch?

I could not see how we could get there before, seeing how the == case is
handled above.

> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
> > @@ -1130,18 +1130,35 @@ static inline void finish_lock_switch(st
> >  extern const int sched_prio_to_weight[40];
> >  extern const u32 sched_prio_to_wmult[40];
> >  
> > +/*
> > + * {de,en}queue flags:
> > + *
> > + * SAVE/RESTORE - an otherwise spurious dequeue/enqueue, done to ensure tasks
> > + *                are in a known state which allows modification. Such pairs
> > + *                should preserve as much state as possible.
> > + *
> > + * MOVE - paired with SAVE/RESTORE, explicitly does not preserve the location
> > + *        in the runqueue.
> > + *
> > + * ENQUEUE_HEAD - place at front of runqueue (tail if not specificed)
> > + *
> > + */
> 
> Do we want to document all the flags while we are at it? :)

Probably.. does the below work? I think I bailed on replenish because I
could not come up with a coherent short description, does the below make
any sense?


--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1140,7 +1140,9 @@ extern const u32 sched_prio_to_wmult[40]
  * MOVE - paired with SAVE/RESTORE, explicitly does not preserve the location
  *        in the runqueue.
  *
- * ENQUEUE_HEAD - place at front of runqueue (tail if not specificed)
+ * ENQUEUE_HEAD      - place at front of runqueue (tail if not specificed)
+ * ENQUEUE_REPLENISH - push the CBS slot forward
+ * ENQUEUE_WAKING    - sched_class::task_waking was called
  *
  */
 

  reply	other threads:[~2016-01-20 10:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-19 11:18 [PATCH] sched: Fix PI handling vs sched_setscheduler() Peter Zijlstra
2016-01-20 10:08 ` Juri Lelli
2016-01-20 10:24   ` Peter Zijlstra [this message]
2016-01-20 10:34     ` Juri Lelli
2016-01-20 11:19       ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160120102425.GI6357@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=juri.lelli@arm.com \
    --cc=juri.lelli@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=parri.andrea@gmail.com \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.