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 11:13:34 +0000	[thread overview]
Message-ID: <42A42FDE.2040600@labristeknoloji.com> (raw)
In-Reply-To: <42A3AA63.7060201@yahoo.com.au>

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


Hello Nick,

Nick Piggin wrote:
> M.Baris Demiray wrote:
> 
> [...]
> Close.
> 
> Probably it would be better to take the intersection of
> (group->cpumask, p->cpus_allowed), and skip the group if
> the intersection is empty.

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?

> In addition to that, do a patch for find_idlest_cpu that
> skips cpus that aren't allowed. You needn't do the cpumask
> check each time round the loop, again just take the
> intersection of the group->cpumask and p->cpus_allowed, and
> loop over that.

Will do it.

> Wanna do a patch for that?

Sure. But I'll wait EOT and do read something more to fill
the gaps.

 > [...]
> 
> I don't think it does anything ;)

LOL. Hope next one'll do.

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;
	}

Thanks for comments.

> 

-- 
"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  8:13 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 [this message]
2005-06-06 10:36     ` Nick Piggin
2005-06-06 13:59       ` M.Baris Demiray

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=42A42FDE.2040600@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.