Date: Fri, 3 Aug 2007 22:59:14 +0200 From: Roman Divacky <rdivacky@FreeBSD.org> To: Jung-uk Kim <jkim@FreeBSD.org> Cc: perforce@FreeBSD.org Subject: Re: PERFORCE change 124529 for review Message-ID: <20070803205914.GA12533@freebsd.org> In-Reply-To: <200708031203.36406.jkim@FreeBSD.org> References: <200708021130.l72BUHrY077198@repoman.freebsd.org> <200708021714.33543.jkim@FreeBSD.org> <20070803081032.GA64605@freebsd.org> <200708031203.36406.jkim@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.diff I already asked attilio@ to review it and hopefully do something about it. > > 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... thank you roman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070803205914.GA12533>