Date: Fri, 3 Aug 2007 12:03:31 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: perforce@FreeBSD.org Cc: Roman Divacky <rdivacky@FreeBSD.org> Subject: Re: PERFORCE change 124529 for review Message-ID: <200708031203.36406.jkim@FreeBSD.org> In-Reply-To: <20070803081032.GA64605@freebsd.org> References: <200708021130.l72BUHrY077198@repoman.freebsd.org> <200708021714.33543.jkim@FreeBSD.org> <20070803081032.GA64605@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200708031203.36406.jkim>