This is the mail archive of the cygwin-patches mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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:
Hi Mark,

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/             |  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 overthinking it.

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.....

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]