Re: Proposed roadmap to 1.0

[Rob Landley <rob@landley.net>]

On 07/24/2013 02:47:19 PM, Rich Felker wrote:
> > So... it's hardwired to 1024 cpus.
> >
> > I don't think there _is_ a way to make this non-ugly. What actually
> > uses this?
> 
> That was my question about the whole affinity system in general. My
> view is that it's stupid micro-management of scheduling that should be
> done by the kernel, and that if the kernel's not doing a good enough
> job of managing which cpu a task runs on, the kernel scheduler should
> be fixed rather than adding hacks in apps.

There are arguments in favor of it, mostly realtime and userspace power  
management. That said, the only thing that _needs_ to use this stuff is  
taskset, and everything else can get called _by_ taskset. Toybox  
implements taskset doesn't use anything out of libc to do so: syscall  
wrappers and managing its own data structures.

Still, you presumably want to build an unmodified util-linux and  
busybox.

The important thing isn't what glibc does, it's what the man pages say.  
I often start by implementing what the documentation says,  
building/running real packages, and then submitting bug reports against  
the docs.

The sched_getaffinity() and sched_setaffinity() syscall wrappers seem  
obvious, and then the _S versions of the macros. Round each size up to  
the next sizeof(long) bytes. That's pretty much the "should implement  
this, push patches upstream to make things use 'em" level.

man 3 CPU_SET says:

   CPU_ALLOC() CPU_FREE()
   CPU_ALLOC_SIZE() // trivial
   CPU_ZERO_S() CPU_SET_S() CPU_CLR_S() CPU_ISSET_S() CPU_COUNT_S()
   CPU_AND_S() CPU_OR_S() CPU_XOR_S() CPU_EQUAL_S()

That set isn't _that_ disgusting. CPU_ALLOC_SIZE(size) is just  
(((((size+7)/8)+3)/4)*4 which makes CPU_ALLOC(size) just be  
malloc(CPU_ALLOC_SIZE(size)) and CPU_FREE(x) is just free(x), and then  
CPU_ZERO_S(size, set) becomes memset(set, 0, size)... I've posted the  
set/isset equations here before, and/or/xor are just a for loop where  
CPU_AND_S(size, dest, src1, src2) is just "do {unsigned __i = size/4;  
while (__i) {dest[__i] = src1[__i] && src2[__i]; __i--;} } while (0)"  
or similar, for CPU_COUNT_S you can just cheat and do a bitwise loop  
with isset (this ain't performance critical)...

If you're bored, you could then make the non-S versions can be macros  
that call the _S versions with a hardwired CPU_SETSIZE argument, and  
obviously that's #defined to 1024. But "don't use deprecated  
interfaces" is also a reasonably response. (If ever there's a reason to  
NOT define stuff unless you #define GNU_DAMMIT it would be the non-S  
versions of these macros. #ifdef GNU_BRAIN_DAMAGE...)

It's evil, but not _that_ evil...

Rob