PERFORCE change 124529 for review
Jung-uk Kim
jkim at FreeBSD.org
Fri Aug 3 15:12:57 PDT 2007
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
More information about the p4-projects
mailing list