Date: Thu, 21 Feb 2008 11:28:27 +0800 From: David Xu <davidxu@FreeBSD.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Daniel Eischen <deischen@FreeBSD.org>, Andrew Gallatin <gallatin@cs.duke.edu>, arch@FreeBSD.org Subject: Re: Linux compatible setaffinity. Message-ID: <47BCEFDB.5040207@freebsd.org> In-Reply-To: <20080220105333.G44565@fledge.watson.org> References: <20071219211025.T899@desktop> <18311.49715.457070.397815@grasshopper.cs.duke.edu> <20080112182948.F36731@fledge.watson.org> <20080112170831.A957@desktop> <Pine.GSO.4.64.0801122240510.15683@sea.ntplx.net> <20080112194521.I957@desktop> <20080219234101.D920@desktop> <20080220101348.D44565@fledge.watson.org> <20080220005030.Y920@desktop> <20080220105333.G44565@fledge.watson.org>
index | next in thread | previous in thread | raw e-mail
Robert Watson wrote: > > On Wed, 20 Feb 2008, Jeff Roberson wrote: > >>> So perhaps this means a slightly more complex API, but not much more >>> complex. How about: >>> >>> int cpuaffinity_get(scope, id, length, mask) >>> int cpuaffinity_getmax(scope, id, length, mask) >>> int cpuaffinity_set(scope, id, length, mask) >>> int cpuaffinity_setmax(scope, id, length, mask) >>> Are these features only for jail or something else which don't care CPU L2 cache sharing between cores ? since program still can not figure out L2 sharing information, no way to optimize its thread's cpu arrangement. Regards, David Xuhelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47BCEFDB.5040207>