From owner-p4-projects@FreeBSD.ORG Fri Aug 3 22:12:57 2007 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id DDFFA16A420; Fri, 3 Aug 2007 22:12:56 +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 AFC6816A418; Fri, 3 Aug 2007 22:12:56 +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 84F6D13C467; Fri, 3 Aug 2007 22:12:56 +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 l73MCtGw017727; Fri, 3 Aug 2007 18:12:55 -0400 (EDT) (envelope-from jkim@FreeBSD.org) From: Jung-uk Kim To: perforce@FreeBSD.org Date: Fri, 3 Aug 2007 18:12:50 -0400 User-Agent: KMail/1.6.2 References: <200708021130.l72BUHrY077198@repoman.freebsd.org> <200708031203.36406.jkim@FreeBSD.org> <20070803205914.GA12533@freebsd.org> In-Reply-To: <20070803205914.GA12533@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200708031812.53069.jkim@FreeBSD.org> 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 22:12:57 -0000 On Friday 03 August 2007 04:59 pm, Roman Divacky wrote: > > > 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. > > yeah yeah.. ;) maybe we can use the same trick linux did. anyway > its ok now. :-) > > > 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. > > http://people.freebsd.org/~ssouhlal/testing/setaffinity-20070707.di >ff > > I already asked attilio@ to review it and hopefully do something > about it. Very cool! > > > thnx for the review! > > > > Thank you! > > so... do you agree that the current revision is fine. I need this > to get kib@ to commit this... Yes. Jung-uk Kim