From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3762 Path: news.gmane.org!not-for-mail From: Rob Landley Newsgroups: gmane.linux.lib.musl.general Subject: Re: Proposed roadmap to 1.0 Date: Sat, 27 Jul 2013 00:30:07 -0500 Message-ID: <1374903007.3031.30@driftwood> References: <20130724194719.GY3249@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1374903019 535 80.91.229.3 (27 Jul 2013 05:30:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 27 Jul 2013 05:30:19 +0000 (UTC) Cc: musl@lists.openwall.com To: musl@lists.openwall.com Original-X-From: musl-return-3766-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jul 27 07:30:21 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1V2x5B-0002Fh-Cj for gllmg-musl@plane.gmane.org; Sat, 27 Jul 2013 07:30:21 +0200 Original-Received: (qmail 3707 invoked by uid 550); 27 Jul 2013 05:30:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 3699 invoked from network); 27 Jul 2013 05:30:20 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=date:from:subject:to:cc:in-reply-to:x-mailer:message-id :mime-version:content-type:content-disposition :content-transfer-encoding:x-gm-message-state; bh=6HwdGo1VxlJzra3JZppzW2S/1TZ1sEYjNmetauyso6M=; b=RdU6Lf6khOh+ELcjP3EZrJnpCeGjmjiHzbFsuodX9zQIq3BuYGX5HZs6DnRfcQuOE1 xsW+/LQLxDOl7ALmamuUdnR49nHHdL3VKiIYW2O4n8lF/CLu8NMHW5tb4BAGtIsW26Qy KYhPQBWTiPQlviIG13WoC/NEdUjIX/5axghxiF+6RiuCDUXvB1typRSPNyyPzVVp730Z UpFxrstBxUO0keRHSZE/UasvsSLMbZ8z2OH0X+vf+LsIAyjHoXhJiYHaKlxNkiOCUbhF NAB5sNxxGwsV5DLR5qcd0v7QTTs8d3Euo6Lr0gdb+tdMSxIXNYTcxfEb+G8eiez9NVE1 QeaA== X-Received: by 10.182.128.42 with SMTP id nl10mr44202956obb.41.1374903008408; Fri, 26 Jul 2013 22:30:08 -0700 (PDT) In-Reply-To: <20130724194719.GY3249@brightrain.aerifal.cx> (from dalias@aerifal.cx on Wed Jul 24 14:47:19 2013) X-Mailer: Balsa 2.4.11 Content-Disposition: inline X-Gm-Message-State: ALoCoQlSVH+kjehfmD/vdW+LNp3pxpy5s/sd9c1JPLQ8u7yIrP3uUKYalLGpxB2mtH5m6qkFAzgY Xref: news.gmane.org gmane.linux.lib.musl.general:3762 Archived-At: 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? >=20 > 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 =20 management. That said, the only thing that _needs_ to use this stuff is =20 taskset, and everything else can get called _by_ taskset. Toybox =20 implements taskset doesn't use anything out of libc to do so: syscall =20 wrappers and managing its own data structures. Still, you presumably want to build an unmodified util-linux and =20 busybox. The important thing isn't what glibc does, it's what the man pages say. =20 I often start by implementing what the documentation says, =20 building/running real packages, and then submitting bug reports against =20 the docs. The sched_getaffinity() and sched_setaffinity() syscall wrappers seem =20 obvious, and then the _S versions of the macros. Round each size up to =20 the next sizeof(long) bytes. That's pretty much the "should implement =20 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 =20 (((((size+7)/8)+3)/4)*4 which makes CPU_ALLOC(size) just be =20 malloc(CPU_ALLOC_SIZE(size)) and CPU_FREE(x) is just free(x), and then =20 CPU_ZERO_S(size, set) becomes memset(set, 0, size)... I've posted the =20 set/isset equations here before, and/or/xor are just a for loop where =20 CPU_AND_S(size, dest, src1, src2) is just "do {unsigned __i =3D size/4; =20 while (__i) {dest[__i] =3D src1[__i] && src2[__i]; __i--;} } while (0)" =20 or similar, for CPU_COUNT_S you can just cheat and do a bitwise loop =20 with isset (this ain't performance critical)... If you're bored, you could then make the non-S versions can be macros =20 that call the _S versions with a hardwired CPU_SETSIZE argument, and =20 obviously that's #defined to 1024. But "don't use deprecated =20 interfaces" is also a reasonably response. (If ever there's a reason to =20 NOT define stuff unless you #define GNU_DAMMIT it would be the non-S =20 versions of these macros. #ifdef GNU_BRAIN_DAMAGE...) It's evil, but not _that_ evil... Rob=