public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Robert Love <rml@tech9.net>
To: Andi Kleen <ak@suse.de>
Cc: Joe Korty <l-k@mindspring.com>, linux-kernel@vger.kernel.org
Subject: Re: [patch] sched_[set|get]_affinity() syscall, 2.4.15-pre9
Date: 27 Nov 2001 16:01:55 -0500	[thread overview]
Message-ID: <1006894915.819.6.camel@phantasy> (raw)
In-Reply-To: <p73lmgssm79.fsf@amdsim2.suse.de>
In-Reply-To: <1006832357.1385.3.camel@icbm.suse.lists.linux.kernel> <5.0.2.1.2.20011127020817.009ed3d0@pop.mindspring.com.suse.lists.linux.kerne l>  <p73lmgssm79.fsf@amdsim2.suse.de>

On Tue, 2001-11-27 at 02:32, Andi Kleen wrote:
> Could you quickly explain an use case where it makes a difference if 
> CPU affinity settings for multiple processes are done atomically or not ? 
> 
> The only way to make CPU affinity settings of processes really atomically 
> without a "consolidation window" is to
> do them before the process starts up. This is easy when they're inherited --
> just set them for the parent before starting the other processes. This 
> works with any interface; proc based or not as long as it inherits.

I assume he meant to prevent the case of setting affinity _after_ a
process forks.  In other words, "atomically" in the sense that it occurs
prior to some action, in order to affect properly all children.

This could be done in program with by writing to the proc entry before
forking, or can be done in a wrapper script (set affinity of self, exec
new task).

cpus_allowed is inherited by all children so this works fine.

	Robert Love


  reply	other threads:[~2001-11-27 21:01 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1006832357.1385.3.camel@icbm.suse.lists.linux.kernel>
     [not found] ` <5.0.2.1.2.20011127020817.009ed3d0@pop.mindspring.com.suse.lists.linux.kernel>
2001-11-27  7:32   ` [patch] sched_[set|get]_affinity() syscall, 2.4.15-pre9 Andi Kleen
2001-11-27 21:01     ` Robert Love [this message]
2001-11-22  8:59 Ingo Molnar
2001-11-22 20:22 ` Davide Libenzi
2001-11-22 23:45 ` Robert Love
2001-11-23  0:20   ` Ryan Cumming
2001-11-23  0:36     ` Mark Hahn
2001-11-23 11:46       ` Ingo Molnar
2001-11-24 22:44         ` Davide Libenzi
2001-11-23  0:51     ` Robert Love
2001-11-23  1:11       ` Andreas Dilger
2001-11-23  1:16         ` Robert Love
2001-11-23 11:36     ` Ingo Molnar
2001-11-24  2:01       ` Davide Libenzi
2001-11-27  3:39     ` Robert Love
2001-11-27  7:13       ` Joe Korty
2001-11-27 20:53         ` Robert Love
2001-11-27 21:31           ` Nathan Dabney
2001-11-27  8:40       ` Ingo Molnar
2001-11-23 11:02   ` Ingo Molnar

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=1006894915.819.6.camel@phantasy \
    --to=rml@tech9.net \
    --cc=ak@suse.de \
    --cc=l-k@mindspring.com \
    --cc=linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox