From owner-p4-projects@FreeBSD.ORG Fri Aug 3 16:03:50 2007 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id B04AB16A420; Fri, 3 Aug 2007 16:03:50 +0000 (UTC) Delivered-To: perforce@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5C82816A419; Fri, 3 Aug 2007 16:03:50 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from anuket.mj.niksun.com (gwnew.niksun.com [65.115.46.162]) by mx1.freebsd.org (Postfix) with ESMTP id C254813C45B; Fri, 3 Aug 2007 16:03:40 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from niksun.com (anuket [10.70.0.5]) by anuket.mj.niksun.com (8.13.6/8.13.6) with ESMTP id l73G3dB0091902; Fri, 3 Aug 2007 12:03:39 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: perforce@FreeBSD.org Date: Fri, 3 Aug 2007 12:03:31 -0400 User-Agent: KMail/1.6.2 References: <200708021130.l72BUHrY077198@repoman.freebsd.org> <200708021714.33543.jkim@FreeBSD.org> <20070803081032.GA64605@freebsd.org> In-Reply-To: <20070803081032.GA64605@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200708031203.36406.jkim@FreeBSD.org> X-Virus-Scanned: ClamAV 0.90.2/3852/Fri Aug 3 10:11:10 2007 on anuket.mj.niksun.com X-Virus-Status: Clean Cc: Roman Divacky Subject: Re: PERFORCE change 124529 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Aug 2007 16:03:51 -0000 On Friday 03 August 2007 04:10 am, Roman Divacky wrote: > > > hm.. I looked at it and in my version the cpumask_t (linux one) > > > is defined to be bit array of configurable length. I dont know > > > what is the default but I think its quite safe to assume that > > > its 128. > > > > Yes, it was but not any more. Basically it depends on Linux > > kernel configuration option, i.e., maximum number of CPUs. Since > > the bit 0 is CPU 0, bit 1 is CPU 1, etc, you have to make sure > > the last bits are properly set. If you really had to do i = ~0, > > you probably wanted to do casting first, e.g., i = ~(cpumask_t)0 > > to make sure. Of course my version doesn't have to worry about > > it. ;-) > > cpumaskt_t is just an unsigned int so ~0 should be fine. For now. ;-) I was thinking about increasing it some time after 7.0 branching. It is very clear that we will need it soon, i.e., multicore CPUs are becoming more common these days. FreeBSD/sun4v already hit the limit with just one processor: http://www.fsmware.com/sun4v/dmesg_latest.txt Even on amd64/i386 world, we will hit it very soon, e.g., octal-core * quad-socket => 32 cores. Without increasing the sizeof(cpumask_t) and/or grouping physical cores per socket, we won't be able to survive very long. > have you looked at my latest revision? the native linux syscall > returns the size of the cpumask_t. ie. the userland knows what is > the maximum that kernel allows. Yes, I did. And I said thanks for catching it. :-) > in FreeBSD it doesnt make any sense to emulate linux size because > if fbsd doesnt support that many CPUs we cannot emulate it. So > using fbsd-sized cpumask_t and telling userland about it is ok. > > agree? Agreed, for 7.0. We should fix it later when we add something like sched_{get,set}affinity() syscalls. > > > but still.. the prototype is: > > > > > > asmlinkage long sys_sched_getaffinity(pid_t pid, unsigned int > > > len, unsigned long __user *user_mask_ptr) > > > > > > and the len is not used anywhere in the code to dynamically > > > size it. I wonder how to deal with that. > > > > The prototype I gave you was from manual page, not the kernel > > source: > > > > http://www.linuxhowtos.org/manpages/2/sched_getaffinity.htm > > yeah.. but this is glibc, I'd prefer to stick with kernel land > interface nomenclature Fine by me, then. > thnx for the review! Thank you! Jung-uk Kim