All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Baron <jbaron@akamai.com>
To: Chris Friesen <cbf123@mail.usask.ca>,
	"linux-kernel@vger.kernel.org >> lkml"
	<linux-kernel@vger.kernel.org>
Cc: Tejun Heo <tj@kernel.org>, lizefan@huawei.com
Subject: Re: question about cpusets vs sched_setaffinity()
Date: Fri, 11 Dec 2015 17:15:21 -0500	[thread overview]
Message-ID: <566B4AF9.10301@akamai.com> (raw)
In-Reply-To: <5669EEFF.20801@mail.usask.ca>



On 12/10/2015 04:30 PM, Chris Friesen wrote:
> Hi,
> 
> I've got a question about the interaction between cpusets and
> sched_setaffinity().
> 
> If I put a task into a cpuset and then call sched_setaffinity() on it,
> it will be affined to the intersection of the two sets of cpus.  (Those
> specified on the set, and those specified in the syscall.)
> 
> However, if I then change the cpus in the cpuset the process affinity
> will simply be overwritten by the new cpuset affinity.  It does not seem
> to take into account any restrictions from the original
> sched_setaffinity() call.
> 
> Wouldn't it make more sense to affine the process to the intersection
> between the new set of cpus from the cpuset, and the current process
> affinity?  That way if I explicitly masked out certain CPUs in the
> original sched_setaffinity() call then they would remain masked out
> regardless of changes to the set of cpus assigned to the cpuset.
> 
> Thanks,
> Chris
> 
> PS: Not subscribed to the list, please CC me on replies.

Hi,

This behavior seems a bit odd to me as well - if you've done a
sched_setaffinity() call to a subset of the cpus of a cpuset that the
task in contained within, any change to the cpuset cpus will wipe away
the sched_setaffinity() settings even if they continue to be a subset of
the cpuset cpus.

To add the behavior you are describing, I think requires another
cpumask_t field in the task_struct. Where we could store the last
requested mask value for sched_setaffinity() and use that when updating
the cpus for a cpuset via an intersection as you described. I think
adding a task to a cpuset still should wipe out any sched_setaffinity()
settings - but that would depend on the desired semantics here. It would
also require a knob so as not to break existing behavior by default.

You could also create a child cgroup for the process that you don't want
to change and set the cpus on that cgroup instead of using
sched_setaffinity(). Then you change the cpus for the parent cgroup and
that shouldn't affect the child as long as the child cgroup is a subset.
But its not entirely clear to me if that addresses your use-case?

Thanks,

-Jason

  reply	other threads:[~2015-12-11 22:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-10 21:30 question about cpusets vs sched_setaffinity() Chris Friesen
2015-12-11 22:15 ` Jason Baron [this message]
2015-12-11 23:26   ` Chris Friesen
2015-12-14 22:14     ` Jason Baron

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=566B4AF9.10301@akamai.com \
    --to=jbaron@akamai.com \
    --cc=cbf123@mail.usask.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=tj@kernel.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.