This is the mail archive of the
mailing list for the Cygwin project.
More oddities with multiple processor groups
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin at cygwin dot com
- Date: Wed, 11 Apr 2018 20:05:04 +0200
- Subject: More oddities with multiple processor groups
I seem to be the first to try Cygwin on a box that has multiple
processor groups, which seems odd. Anyway, I've already noticed two
more things that indicate that Cygwin and/or Cygwin applications
currently don't deal well with the situation:
1. Trying to run top, it shows only the first 16 processors and then
exits with an error that "openproc failed". Interestingly enough it
will keep running despite this error when running under strace (still
only showing the processors from one group, presumably the one that top
got started in).
2. Git will correctly determine that it can use 32 threads for garbage
collection, but it starts them all in the same processor group.
The problem here is that on Linux you don't need to do anything extra to
use any of the advertised logical processors from a single application,
while on Windows you need to first create a thread and set it's affinity
to a different group than where your process was started in, then assign
each new thread an affinity to one of the available groups. If you
don't do that, all threads will be restricted to the original group.
Some more info on these differences (and already a bit outdated
w.r.t. the way processor groups are formed):
If it would be possible for Cygwin to hide that ugliness from Cygwin
applications I think that'd be highly welcome. Otherwise there might
need to be some option to restrict Cygwin to a single processor group
for some applications to work (correctly).
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Factory and User Sound Singles for Waldorf rackAttack:
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple