From owner-freebsd-arch@FreeBSD.ORG Fri Dec 21 01:39:03 2007 Return-Path: Delivered-To: arch@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DA6D416A420 for ; Fri, 21 Dec 2007 01:39:03 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D06D613C448; Fri, 21 Dec 2007 01:39:03 +0000 (UTC) (envelope-from davidxu@FreeBSD.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id lBL1cwWj080728; Fri, 21 Dec 2007 01:39:00 GMT (envelope-from davidxu@freebsd.org) Message-ID: <476B1973.6070902@freebsd.org> Date: Fri, 21 Dec 2007 09:40:03 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20071211) MIME-Version: 1.0 To: Jeff Roberson References: <20071219211025.T899@desktop> In-Reply-To: <20071219211025.T899@desktop> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@FreeBSD.org Subject: Re: Linux compatible setaffinity. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2007 01:39:03 -0000 Jeff Roberson wrote: > I have implemented a linux compatible sched_setaffinity() call which is > somewhat crippled. This allows a userspace process to supply a bitmask > of processors which it will run on. I have copied the linux interface > such that it should be api compatible because I believe it is a sensible > interface and they beat us to it by 3 years. > > My implementation is crippled in that it supports binding by curthread > only and to a single cpu only. Neither of the schedulers presently > support binding to multiple cpus or binding a non-curthread thread. > This property is not inherited by forked threads and does not effect > other threads in the same process. These two limitations can gradually > be weakened without effecting the syscall api. > > The linux api is: > int sched_setaffinity(pid_t pid, unsigned int cpusetsize, cpu_set_t > *mask); > > The cpu_set_t is the same as a fdset for select. The cpusetsize > argument is used to determine the size of the array in mask. > > I'm mostly interested in feedback on how best to reduce the namespace > pollution and avoid pulling the sched.h file into the generated syscall > files (sysproto.h, etc). Anyone who feels this is a terrible interface > for such a thing should speak up now. > > I also feel that in the medium term we will have to deal with machines > with more cores than bits in their native word. Using these CPU_SET, > CPU_CLR macros is a fine way to deal with this issue. > > I also have a primitive 'taskset', although I don't like the name, it > allows you to run arbitrary programs bound to a single cpu. > > Thanks, > Jeff > I don't say no to these interfaces, but there is a need to tell user which cpus are sharing cache, or memory distance is closest enough, and which cpus are servicing interrupts, e.g, network interrupt and disks etc, etc, otherwise, blindly setting cpu affinity mask only can shoot itself in the foot. Regards, David Xu