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