This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH] Cygwin: Implement CPU_SET(3) macros
On Fri, 26 Jul 2019, Corinna Vinschen wrote:
On Jul 25 14:15, Mark Geisert wrote:
Corinna Vinschen wrote:
On Jul 1 01:55, Mark Geisert wrote:
Corinna Vinschen wrote:
On Jun 30 15:59, Mark Geisert wrote:
This patch supplies an implementation of the CPU_SET(3) processor
affinity macros as documented on the relevant Linux man page.
winsup/cygwin/include/sys/cpuset.h | 62 +++++++++++++++++++++++++++---
winsup/cygwin/sched.cc | 8 ++--
2 files changed, 60 insertions(+), 10 deletions(-)
+#define CPU_SETSIZE 1024 // maximum number of logical processors tracked
+#define NCPUBITS (8 * sizeof (__cpu_mask)) // max size of processor group
+#define CPU_GROUPMAX (CPU_SETSIZE / NCPUBITS) // maximum group number
-#define __CPUELT(cpu) ((cpu) / __NCPUBITS)
-#define __CPUMASK(cpu) ((__cpu_mask) 1 << ((cpu) % __NCPUBITS))
+#define CPU_WORD(cpu) ((cpu) / NCPUBITS)
+#define CPU_MASK(cpu) ((__cpu_mask) 1 << ((cpu) % NCPUBITS))
I wouldn't do that. Three problems:
There's also the request from Sebastian on the newlib list to
consolidate the cpuset stuff from RTEMS and Cygwin into a single
I've also found that taskset isn't working properly on my build system with
the new CPU_SET code, though my other testcases are. So even as submitted,
and fixed per your comments here, there's a bit more to be done.
any chance to pick this up again?
I've been looking at this suggestion to consolidate the cpuset stuff from
RTEMS and Cygwin. There is no location common to both platforms to put
this stuff other than Newlib's libc directory or maybe a non-sys subdir
of libc. If situated there, it could impact other newlib platforms,
possibly. It also seems a little messy to me to have to put four include
files there.. cpuset.h, _cpuset.h, bitset.h, and _bitset.h. Maybe I'm
RTEMS' cpuset.h is built on bitset.h, which is fine but the cpuset.h I
wrote is self-contained and makes use of gcc builtins rather than C
library calls for malloc, free, popcount, etc. Mine is 32/64 agnostic, I
believe RTEMS is too but I'm not totally sure; it depends on the length
of 'long' items.
RTEMS' implementation includes some code modules needing to be linked into
libc while the one I wrote is all in header files with some inline code.
These are all just minor implementation differences but I'm still hung up
on the question of just where a common implementation could be placed in
the source tree so both RTEMS and Cygwin can use them but other newlib
platforms won't be tripped up.
P.S. IRC would be better for this kind of discussion. I'm waiting for my
freenode registration to be processed.....