From owner-freebsd-arch@FreeBSD.ORG Sun Dec 23 06:35:16 2007 Return-Path: Delivered-To: arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B9A4F16A419; Sun, 23 Dec 2007 06:35:16 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from webaccess-cl.virtdom.com (webaccess-cl.virtdom.com [216.240.101.25]) by mx1.freebsd.org (Postfix) with ESMTP id 7CE7513C448; Sun, 23 Dec 2007 06:35:16 +0000 (UTC) (envelope-from jroberson@chesapeake.net) Received: from [192.168.1.107] (cpe-24-94-75-93.hawaii.res.rr.com [24.94.75.93]) (authenticated bits=0) by webaccess-cl.virtdom.com (8.13.6/8.13.6) with ESMTP id lBN6ZEmS017221; Sun, 23 Dec 2007 01:35:15 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Sat, 22 Dec 2007 20:36:32 -1000 (HST) From: Jeff Roberson X-X-Sender: jroberson@desktop To: David Xu In-Reply-To: <476B1973.6070902@freebsd.org> Message-ID: <20071222203443.U899@desktop> References: <20071219211025.T899@desktop> <476B1973.6070902@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Sun, 23 Dec 2007 06:35:16 -0000 On Fri, 21 Dec 2007, David Xu wrote: > 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. I don't disagree with you, however, I think in most cases the affinity mask is used for very special purpose applications. In the cases I have observed, anyhow, the application is tailored to the particular machine. So hopefully the programmer knows these things. I would prefer that it not crop up as a general interface that normal applcations use to try to improve performance. We should hope that we can improve the schedulers to do these things automatically. Thanks, Jeff > > Regards, > David Xu >