From owner-svn-src-all@FreeBSD.ORG Wed Oct 27 13:06:08 2010 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7FC101065673; Wed, 27 Oct 2010 13:06:08 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 618E28FC23; Wed, 27 Oct 2010 13:06:07 +0000 (UTC) Received: by wyb42 with SMTP id 42so662515wyb.13 for ; Wed, 27 Oct 2010 06:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=GrOIE+apgTk8JYgo7/kc4XZOmtInF1metD36zLLIy9w=; b=lXjeFm/TdyINbiWYr9rMKxaWmI2uvtgjM45y06FfMSRPGol8ecSZWz3bfKCmx0OegX pTX/X3OUM6I7VS6+LWzqZfEQs7YVkn47DZdHBT617xXv5E7YzuQazVseBbHw6q9X8MP1 F1NQcMT6uTqY7YwtgRJ1VVl0I97BbkFmMpiqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fTlW5CgH07GhU6OLHKr5ljF+SEBNvuTcMtDDJFoj/FSzp7PmpP/GiLI2QBuxP5fe18 22YZubTbzB2fPNvImwQQsASL4mbuO5bHnRbt9gg1xv7gg9m1yVATVt51x6dploOMV2pi JycXcun1Mh9vxv55j3neQYl0BHW9uMRm4s/c4= MIME-Version: 1.0 Received: by 10.216.1.6 with SMTP id 6mr9025440wec.24.1288184766388; Wed, 27 Oct 2010 06:06:06 -0700 (PDT) Sender: yanegomi@gmail.com Received: by 10.216.10.198 with HTTP; Wed, 27 Oct 2010 06:06:06 -0700 (PDT) In-Reply-To: <4CC82195.5000201@freebsd.org> References: <201010270232.o9R2Wsu3084553@svn.freebsd.org> <4CC803A8.3040602@freebsd.org> <4CC80ABA.3080404@freebsd.org> <4CC82195.5000201@freebsd.org> Date: Wed, 27 Oct 2010 06:06:06 -0700 X-Google-Sender-Auth: shMS-QCBUz651ZiaUXXXhE5PHIE Message-ID: From: Garrett Cooper To: David Xu Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Robert Watson Subject: Re: svn commit: r214409 - head/sys/kern X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2010 13:06:08 -0000 On Wed, Oct 27, 2010 at 5:56 AM, David Xu wrote: > Robert Watson wrote: >> >> On Wed, 27 Oct 2010, David Xu wrote: >> >>>>> I really hate to see such a problem that userland can not figure out >>>>> what kernel is using, I try hardly to guess, but still can not find w= hat it >>>>> is using. yes, I think the doc may need to be fixed or another syscal= l is >>>>> needed. >>>> >>>> =A0 =A0Well... Jeff's code in cpuset(1) does some trivial sizeof(mask)= 's, >>>> but it just passes in cpuset_t for mask. I've seen different calling >>>> conventions at the kernel level when I tried to get my brain in sync w= ith >>>> that for a bug I was looking at a few weeks ago (and sadly, failed to = some >>>> degree). >>>> =A0 =A0These syscalls are a bit confusing though, and apart from cpuse= t(1) >>>> there aren't any really good examples in the sourcebase on how to use = them >>>> (at least not the last time I checked)... Thanks, -Garrett >>>> >>> The problem is that the size of cpuset is not fixed, it is tunable by t= he >>> recompiling kernel with different parameter, so if you have a program w= hich >>> you want to adapt it to use any size of cpuset, it should be able to ge= t the >>> size the kernel is using, if you don't have source code of the program,= you >>> can not compile it with new parameter, then there is trouble. >> >> Yay, it's fd_set all over again :-). >> >> It sounds like we might just need to add a sysctl and a few wrapper >> functions in userspace along the lines of (hand-wave): >> >> cpuset_t =A0 =A0*cpuset_alloc(); >> void =A0 =A0 =A0 =A0 cpuset_free(); >> >> And perhaps some sort of API that abstracts manipulation of the set (or >> doesn't but allows the user to easily query its bounds). >> >> Robert >> > Problem is who will use the non-standard interface ? The > pthread_attr_getaffinity_np pthread_attr_setaffinity_np > and others are from glibc, which let you specify arbitrary > cpuset size but kernel only accept one size. =A0:-) > > Though it is not POSIX, but some software start to use it, AFAIK, > Erlang language's VM start to use it for binding its scheduler > thread to cpu, we have to live with it. We still lack of some functions > to let it compile without modification, one is it wants to know > cpu topology, and other crappy functions it wants to use is: > sched_getaffinity, sched_setaffinity, which one guy thought each > thread is just a process which has a =A0PID. =A0:-) > I don't know how it uses Solaris processor binding interface. I brought this up a while back over the Austin Group list, but it looks like I need to file an Aardvark ticket for it and attend the meetings so the OpenGroup folks actually take the issue to heart.