From: Nathan Lynch <ntl@pobox.com>
To: Paul Jackson <pj@sgi.com>
Cc: Jack Steiner <steiner@sgi.com>,
mingo@elte.hu, linux-kernel@vger.kernel.org,
Robert Love <rml@novell.com>
Subject: Re: 2.6.16 - sys_sched_getaffinity & hotplug
Date: Fri, 27 Jan 2006 21:42:41 -0600 [thread overview]
Message-ID: <20060128034241.GB18730@localhost.localdomain> (raw)
In-Reply-To: <20060127191400.aacb8539.pj@sgi.com>
Paul Jackson wrote:
> Jack wrote:
> > Should the following change be made to sched_getaffinity().
> >
> > Index: linux/kernel/sched.c
> > ===================================================================
> > --- linux.orig/kernel/sched.c 2006-01-25 08:50:21.401747695 -0600
> > +++ linux/kernel/sched.c 2006-01-27 16:57:24.504871895 -0600
> > @@ -4031,7 +4031,7 @@ long sched_getaffinity(pid_t pid, cpumas
> > goto out_unlock;
> >
> > retval = 0;
> > - cpus_and(*mask, p->cpus_allowed, cpu_possible_map);
> > + cpus_and(*mask, p->cpus_allowed, cpu_online_map);
>
> Adding Robert Love to the cc list, as he is Mr. sched_getaffinity,
> I believe.
>
> I ended up doing a similar change, to the cpus (and mems) masks
> in the root (all encompassing) cpuset.
Which is problematic, because cpuset_cpus_allowed ->
guarantee_online_cpus restricts the task->cpus_allowed mask to cpus
which happen to be online at the time of the call to
sched_setaffinity. If more cpus come online later, that task can't be
migrated to them.
> These now show the values
> of cpu_online_map and node_online_map, not *_MASK_ALL.
>
> My hunches are:
> * This change to cpu_online_map is a good one.
It's not.
> * The man page sentence "Usually, all bits in the mask are set."
> might have meant something when it was written, but it is not
> now clear what.
I think it could reasonably be interpreted as all bits in the mask are
set unless the task's affinity has been modified.
next prev parent reply other threads:[~2006-01-28 3:42 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-27 23:06 2.6.16 - sys_sched_getaffinity & hotplug Jack Steiner
2006-01-28 2:58 ` Nathan Lynch
2006-01-29 13:06 ` Jack Steiner
2006-01-28 3:14 ` Paul Jackson
2006-01-28 3:42 ` Nathan Lynch [this message]
2006-01-28 4:58 ` Paul Jackson
2006-01-28 5:23 ` Nathan Lynch
2006-01-28 6:40 ` Paul Jackson
2006-01-28 7:04 ` Paul Jackson
2006-01-28 13:32 ` Ingo Molnar
2006-01-28 16:08 ` Jack Steiner
2006-01-28 19:27 ` Nathan Lynch
2006-01-28 20:06 ` Paul Jackson
2006-01-29 13:51 ` [PATCH] " Jack Steiner
2006-01-28 20:09 ` 2.6.16 " Paul Jackson
2006-01-28 20:50 ` Robert Love
2006-01-28 21:00 ` Paul Jackson
2006-01-29 13:01 ` Ingo Molnar
2006-01-29 16:09 ` Robert Love
2006-01-29 17:26 ` Paul Jackson
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=20060128034241.GB18730@localhost.localdomain \
--to=ntl@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=pj@sgi.com \
--cc=rml@novell.com \
--cc=steiner@sgi.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 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.