All of lore.kernel.org
 help / color / mirror / Atom feed
From: "M.Baris Demiray" <baris@labristeknoloji.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2.6.12-rc5-mm2] [sched] add allowed CPUs check into find_idlest_group()
Date: Mon, 06 Jun 2005 13:59:18 +0000	[thread overview]
Message-ID: <42A456B6.7070106@labristeknoloji.com> (raw)
In-Reply-To: <42A42745.9080103@yahoo.com.au>

[-- Attachment #1: Type: text/plain, Size: 1579 bytes --]


Nick Piggin wrote:
> M.Baris Demiray wrote:
 > [...]
>>
>> But, isn't it required for us to be allowed to run on _every_
>> CPU in that group. If we take intersection and continue if
>> that's not empty, then there could be CPUs in group that are
>> not allowed. Since any CPU then can be the idlest in that
>> group we can be assigned to a CPU that is not allowed.
>> Missing something?
>>
> 
> That should be OK. We basically aren't too interested in
> exactly which CPU it should go to, but just that it should
> go to that group.
> 
> If the group is determined to be the idlest, and there is
> a CPU that can run the task, then that's all we need.

OK. And also I missed the point that you requested a second check
in find_idlest_cpu() which'll prevent an assignment to an unallowed
CPU. That will solve the problem.

 > [...]
>>
>> Meanwhile, what is the problem with that patch? Not traversing
>> the CPUs correctly or continue;ing is wrong?
>>
>>     for_each_cpu_mask(i, group->cpumask) {
>>         if (!cpu_isset(i, p->cpus_allowed))
>>             continue;
>>     }
>>
> 
> In Linux, the for_* macros actually *are* for loops. So that is
> that loop that your continue continues, and seeing as it is at
> the end of that for loop, it does nothing.

Argh. I'll look at these.

Thanks Nick.

> Thanks,
> Nick
> 

-- 
"You have to understand, most of these people are not ready to be
unplugged. And many of them are no inert, so hopelessly dependent
on the system, that they will fight to protect it."
                                                         Morpheus

[-- Attachment #2: baris.vcf --]
[-- Type: text/x-vcard, Size: 342 bytes --]

begin:vcard
fn:M.Baris Demiray
n:Demiray;M.Baris
org:Labris Teknoloji
adr:;;Teknokent Silikon Bina No:24 ODTU;Ankara;;06531;Turkey
email;internet:baris@labristeknoloji.com
title:Yazilim Gelistirme Uzmani
tel;work:+903122101490
tel;fax:+903122101492
x-mozilla-html:FALSE
url:http://www.labristeknoloji.com
version:2.1
end:vcard


      reply	other threads:[~2005-06-06 10:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-05 17:36 [PATCH 2.6.12-rc5-mm2] [sched] add allowed CPUs check into find_idlest_group() M.Baris Demiray
2005-06-06  1:44 ` Nick Piggin
2005-06-06 11:13   ` M.Baris Demiray
2005-06-06 10:36     ` Nick Piggin
2005-06-06 13:59       ` M.Baris Demiray [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=42A456B6.7070106@labristeknoloji.com \
    --to=baris@labristeknoloji.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nickpiggin@yahoo.com.au \
    /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.