[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1374903007.3031.30@driftwood>
Date: Sat, 27 Jul 2013 00:30:07 -0500
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com
Cc: musl@...ts.openwall.com
Subject: Re: Proposed roadmap to 1.0
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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
