public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Yong Zhang <yong.zhang0@gmail.com>
Cc: Hillf Danton <dhillf@gmail.com>,
	LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <peterz@infradead.org>,
	Mike Galbraith <efault@gmx.de>
Subject: Re: [PATCH] sched: correct how RT task is picked
Date: Tue, 17 May 2011 21:38:42 -0400	[thread overview]
Message-ID: <20110518013842.GD23940@home.goodmis.org> (raw)
In-Reply-To: <20110512120606.GA3639@zhy>

On Thu, May 12, 2011 at 08:06:06PM +0800, Yong Zhang wrote:
> On Wed, May 11, 2011 at 09:44:04PM +0800, Hillf Danton wrote:
> > On Wed, May 11, 2011 at 4:43 PM, Yong Zhang <yong.zhang0@gmail.com> wrote:
> > > On Tue, May 10, 2011 at 9:04 PM, Hillf Danton <dhillf@gmail.com> wrote:
> > >> When picking RT task for given CPU,
> > >> [1] if the cpu is invalid for cpumask test, right result could not be
> > >
> > > 'cpu is invalid' means weather we care it or not, it's not real 'invalid'
> > >
> > If cpu is not cared, how to determine whether it is allowed for task to run?
> 
> pick_next_highest_task_rt() can be used to get the next highest pullable
> task on a certain rq(regradless on which cpu that task could run). but
> currently we have no such kind of caller.
> 
> > 
> > >> reached even by further checking nr_cpus_allowed,
> > >> on the other hand, the input cpu is valid in two cases that
> > >> pick_next_highest_task_rt() is called, thus the invalid input cpu
> > >> looks over-concern.
> > >> [2] if the cpu is valid for cpumask test, further checking
> > >> nr_cpus_allowed looks overwork, since it is computed based on
> > >> cpus_allowed,
> > >
> > > No, cpumask_test_cpu(cpu, &p->cpus_allowed) doesn't mean
> > > p->rt.nr_cpus_allowed > 1.
> > >
> > If cpu is allowed for task to run, then why more cpus are enforced?
> 
> I think you can take a look at next_prio(), it just calculate the
> next highest task on the current cpu; in this case,
> cpumask_test_cpu(cpu, &p->cpus_allowed) will be true for the most
> of time, but maybe that task is bound to this cpu.

I've been looking at the history here, and I think that '-1' is a relic.

If you look at sched_rt.c in f65eda4f789168ba5ff3fa75546c29efeed19f58:

$ git show f65eda4f:kernel/sched_rt.c 

You'll see that push_rt_task calls pick_next_highest_task_rt() with a
-1. That code has long been replaced.

I'm a bit nervous about taking Hillf's patch as is. But a little more
reviewing and testing may prove that it is legit.

-- Steve


  reply	other threads:[~2011-05-18  1:38 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-10 13:04 [PATCH] sched: correct how RT task is picked Hillf Danton
2011-05-11  8:43 ` Yong Zhang
2011-05-11 13:44   ` Hillf Danton
2011-05-12 12:06     ` Yong Zhang
2011-05-18  1:38       ` Steven Rostedt [this message]
2011-05-18  2:31         ` Yong Zhang
2011-05-18 13:19           ` Hillf Danton
2011-05-18 13:24             ` Steven Rostedt
2011-05-18 14:46               ` Hillf Danton
2011-05-18 15:15                 ` Steven Rostedt
2011-05-18 15:20                   ` Peter Zijlstra
2011-05-19 12:49                     ` [PATCH resend] " Hillf Danton
2011-05-19  1:41                 ` [PATCH] " Yong Zhang
2011-05-19  1:44                   ` Yong Zhang

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=20110518013842.GD23940@home.goodmis.org \
    --to=rostedt@goodmis.org \
    --cc=dhillf@gmail.com \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=yong.zhang0@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox