This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Tue Apr 23 19:24:17 2024 Received: from spaans.ds9a.nl (adsl-xs4all.ds9a.nl [213.84.159.51]) by kylie.puddingonline.com (8.11.6/8.11.6) with SMTP id g8IGJ5X29380 for ; Wed, 18 Sep 2002 18:19:06 +0200 Received: (qmail 3379 invoked from network); 18 Sep 2002 07:12:30 -0000 Received: from unknown (HELO spaans.ds9a.nl) (3ffe:8280:10:360:202:44ff:fe2a:a1dd) by mayo.ipv6.ds9a.nl with SMTP; 18 Sep 2002 07:12:30 -0000 Received: (qmail 13609 invoked by uid 1000); 17 Sep 2002 20:47:52 -0000 Received: (maildatabase); juh Received: (qmail 1954 invoked by alias); 6 Dec 2001 08:55:18 -0000 Received: (qmail 1720 invoked from network); 6 Dec 2001 08:55:09 -0000 Received: from unknown (HELO dipsaus.ds9a.tudelft.nl) (::ffff:10.0.0.202) by spaans.ds9a.nl with SMTP; 6 Dec 2001 08:55:09 -0000 Received: (qmail 31354 invoked from network); 6 Dec 2001 02:29:33 -0000 Received: from unknown (HELO vger.kernel.org) (::ffff:199.183.24.194) by hinterlink.xs4all.nl with SMTP; 6 Dec 2001 02:29:33 -0000 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Wed, 5 Dec 2001 21:22:29 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Wed, 5 Dec 2001 21:22:20 -0500 Received: from e1.ny.us.ibm.com ([32.97.182.101]:12502 "EHLO e1.ny.us.ibm.com") by vger.kernel.org with ESMTP id ; Wed, 5 Dec 2001 21:22:04 -0500 Received: from northrelay01.pok.ibm.com (northrelay01.pok.ibm.com [9.117.200.21]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id VAA307216; Wed, 5 Dec 2001 21:19:12 -0500 Received: from us.ibm.com (dyn9-47-17-243.des.beaverton.ibm.com [9.47.17.243]) by northrelay01.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id fB62LtN38056; Wed, 5 Dec 2001 21:21:55 -0500 Message-Id: <3C0ED52E.B15F0ED7@us.ibm.com> Date: Wed, 05 Dec 2001 18:17:18 -0800 From: Matthew Dobson X-Mailer: Mozilla 4.76 [en] (X11; U; Linux 2.4.2-2 i686) X-Accept-Language: en Mime-Version: 1.0 To: Davide Libenzi Cc: lkml Subject: Re: [RFC][PATCH] cpus_allowed/launch_policy patch, 2.4.16 References: <3C0ECBE0.F21464FA@us.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org X-Spam-Tag: 1 Lines: 103 Davide Libenzi wrote: > > On Wed, 5 Dec 2001, Matthew Dobson wrote: > > > In response (albeit a week plus late) to the recent hubbub about the cpu > > affinity patches, > > I'd like to throw a third contender in the ring. > > > > Attatched is a patch (against 2.4.16) which implements a /proc and a prctl() > > interface to > > the cpus_allowed flag. The truly exciting (at least for me) part of this patch > > is the > > launch_policy flag that it also introduces. The launch_policy flag is used > > similarly to > > the cpus_allowed flag, but it controls the cpus_allowed flags of any subsequent > > children > > of the process, instead of the cpus_allowed of the process itself. Via this > > flag, there > > are no worries about processes being able to fork children before a 'chaff' or > > 'echo' or > > anything else for that matter can be executed. The child process is assigned > > the desired > > cpus_allowed at fork/exec time. All this without having to bounce the current > > process to > > different cpus to (hopefully) acheive the same results. > > > > The launch_policy flag can acually be quite powerful. It allows for children > > to be > > instantiated on the correct cpu/node with a minimum of memory footprint on the > > wrong > > cpu/node. This can be taken advantage of via the /proc interface (for smp/numa > > unaware > > programs) or through prctl() for more clueful programs. > > What you probably want to do in real life is to move a process to a cpu > and have all its child spawned on that cpu, that is the actual behavior. If you want a process moved, you change cpus_allowed; if you want the children spawned somewhere in particular, you change launch_policy; if you really want both, you change both... > Can't You achieve the same by coding a : > > pid_t affine_fork(int cpumask) { > pid_t pp = fork(); > if (pp == 0) { > set_affinity(getpid(), cpumask); > ... > } > return pp; > } > > in your application and having the default bahavior to propagate it to the > following fork()s. you could do that, but that means you have to keep track of the cpumask somewhere. i suppose you could force your children to: pid_t enforce_launch_policy_fork() { pid_t pp = fork(); if (pp == 0) { set_affinity(getpid(), get_affinity()); ... } return pp; } but, as soon as one of them exec()'s their no longer going to be using your functions. By making it a default part of fork's behavior, processes naturally end up where they're supposed to be. And the default launch_policy if 0xffffffff, so unless you purposely change launch_policy, the old default behavior (run wherever you can) is preserved. > > > +int proc_pid_cpus_allowed_read(struct task_struct *task, char * buffer) > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > You want Al Viro screaming, don't You ? :) > > - Davide If that is the biggest complaint about the patch, then I'll be quite happy with some yelling and screaming about descriptive function names! ;) Cheers! -matt > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/