From owner-cvs-all@FreeBSD.ORG Mon Mar 3 09:34:37 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9A13D1065671; Mon, 3 Mar 2008 09:34:37 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from mta5.srv.hcvlny.cv.net (mta5.srv.hcvlny.cv.net [167.206.4.200]) by mx1.freebsd.org (Postfix) with ESMTP id 717398FC32; Mon, 3 Mar 2008 09:34:37 +0000 (UTC) (envelope-from aryeh.friedman@gmail.com) Received: from flosoft.no-ip.biz (ool-435559b8.dyn.optonline.net [67.85.89.184]) by mta5.srv.hcvlny.cv.net (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTP id <0JX5009CAD7O9YE0@mta5.srv.hcvlny.cv.net>; Mon, 03 Mar 2008 04:04:36 -0500 (EST) Received: from flosoft.no-ip.biz (localhost [IPv6:::1]) by flosoft.no-ip.biz (8.14.2/8.14.2) with ESMTP id m2394ZQ8007252; Mon, 03 Mar 2008 04:04:35 -0500 Date: Mon, 03 Mar 2008 04:04:30 -0500 From: "Aryeh M. Friedman" In-reply-to: <47CBBE21.4060104@freebsd.org> To: David Xu Message-id: <47CBBF1E.8060701@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Enigmail-Version: 0.95.6 References: <200803020739.m227dNLe039427@repoman.freebsd.org> <47CBBE21.4060104@freebsd.org> User-Agent: Thunderbird 2.0.0.12 (X11/20080303) Cc: cvs-src@FreeBSD.org, Jeff Roberson , src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/conf files src/sys/kern init_main.c kern_cpuset.c kern_thread.c syscalls.master src/sys/sys _types.h cpuset.h proc.h types.h src/lib/libc/sys Symbol.map X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 09:34:37 -0000 David Xu wrote: > Jeff Roberson wrote: >> jeff 2008-03-02 07:39:22 UTC >> >> FreeBSD src repository >> >> Modified files: >> sys/conf files sys/kern init_main.c >> kern_thread.c syscalls.master sys/sys _types.h >> types.h proc.h lib/libc/sys Symbol.map Added files: >> sys/kern kern_cpuset.c sys/sys >> cpuset.h Log: >> Add cpuset, an api for thread to cpu binding and cpu resource grouping >> and assignment. >> - Add a reference to a struct cpuset in each thread that is >> inherited from >> the thread that created it. >> - Release the reference when the thread is destroyed. >> - Add prototypes for syscalls and macros for manipulating cpusets in >> sys/cpuset.h >> - Add syscalls to create, get, and set new numbered cpusets: >> cpuset(), cpuset_{get,set}id() >> - Add syscalls for getting and setting affinity masks for cpusets or >> individual threads: cpuid_{get,set}affinity() >> - Add types for the 'level' and 'which' parameters for the >> cpuset. This >> will permit expansion of the api to cover cpu masks for other >> objects >> identifiable with an id_t integer. For example, IRQs and Jails >> may be >> coming soon. >> - The root set 0 contains all valid cpus. All thread initially >> belong to >> cpuset 1. This permits migrating all threads off of certain >> cpus to >> reserve them for special applications. >> Sponsored by: Nokia >> Discussed with: arch, rwatson, brooks, davidxu, deischen >> Reviewed by: antoine >> > > The cpuset_setaffinity with command CPU_WHICH_TID may hurt another > process if a weird process is out of the control. > The current code intents to lookup globally a thread has exact thread > id, because thread may be created and exited quickly, and thread ID is > reused quickly too, it is possible the weird process gives an outdated > thread ID to the API, and an irrelvant thread within another process > belongs to same user gets bind to cpus, such problem is very difficult > to be diagnosed when it happens, and it is an administrator is > nightmare. I think there should be a CPU_WHICH_TID_LOCAL command > to limit the searching scope in current process, and in most case, > the CPU_WHICH_TID_LOCAL will be used instead. Would lack of this cause binaries compiled against a non-cpuset schedular to panic a cpuset one? Specifically when I was attempting to verify the performence gain I commented out all *_affinity items in sched_ule.c and kern_cpuset.c and it booted fine but panicked if any forks from the shell occured (i.e. tcsh came up fine in single user mode but *ANY* external command sent it into a panic)