From: Gregory Haskins <gregory.haskins@gmail.com>
To: Lucas De Marchi <lucas.de.marchi@gmail.com>
Cc: Gregory Haskins <ghaskins@novell.com>,
Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
Peter Zijlstra <peterz@infradead.org>,
linux-kernel@vger.kernel.org
Subject: Re: [lucas.de.marchi@gmail.com: Bug when changing cpus_allowed of RT tasks?]
Date: Mon, 09 Nov 2009 20:15:37 -0500 [thread overview]
Message-ID: <4AF8BEB9.1070103@gmail.com> (raw)
In-Reply-To: <193b0f820911091312y125209deufadd1040aff65cfd@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1751 bytes --]
Lucas De Marchi wrote:
> On Mon, Nov 9, 2009 at 17:35, Gregory Haskins <ghaskins@novell.com> wrote:
>
>>> static int select_task_rq_rt(struct task_struct *p, int sd_flag, int flags)
>>> {
>>> [...]
>>> if (unlikely(rt_task(rq->curr)) &&
>>> (p->rt.nr_cpus_allowed > 1)) {
>>> int cpu = find_lowest_rq(p);
>>>
>>> return (cpu == -1) ? task_cpu(p) : cpu;
>>> }
> /*
> * Otherwise, just let it ride on the affined RQ and the
> * post-schedule router will push the preempted task away
> */
> return task_cpu(p);
>
>>> }
> I completed the rest of function to emphasize it will return task_cpu(p)
> afterwards.
>
>> So the intent of this logic is to say "if the task is of type RT, and it can move, see if it can move
>> elsewhere". Otherwise, we do not try to move it at all.
>
> I'd say "if _current_ is of type RT, and _p_ can move, see if _p_ can move
> elsewhere". And this check is repeated for p inside find_lowest_rq, so it would
> not be needed here. Just let it call find_lowest_rq and -1 will be returned.
Ah, yes, "current" is correct. My bad.
>
>> Until further evidence is presented, I have to respectfully NAK the patch, as I do not think its doing the right thing
>> nor do I think the current code is actually broken.
>
> I see now it's not doing the right thing. IMO only the double check of
> rt.nr_cpus_allowed is superfluous, but not wrong.
>
Right. I have a suspicion that the original code didn't have the
redundant check, but it was patched that way later. I can't recall, tbh.
>
> Thanks for clarifications
Np.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
prev parent reply other threads:[~2009-11-10 1:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20091108121650.GB11372@elte.hu>
2009-11-09 19:35 ` [lucas.de.marchi@gmail.com: Bug when changing cpus_allowed of RT tasks?] Gregory Haskins
2009-11-09 21:12 ` Lucas De Marchi
2009-11-10 1:15 ` Gregory Haskins [this message]
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=4AF8BEB9.1070103@gmail.com \
--to=gregory.haskins@gmail.com \
--cc=ghaskins@novell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lucas.de.marchi@gmail.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
/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.