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