public inbox for
 help / color / mirror / Atom feed
From: Achim Gratz <>
Subject: More oddities with multiple processor groups
Date: Wed, 11 Apr 2018 18:05:00 -0000	[thread overview]
Message-ID: <87in8xwre7.fsf@Rainer.invalid> (raw)

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:
Unsubscribe info:

             reply	other threads:[~2018-04-11 18:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-11 18:05 Achim Gratz [this message]
2018-04-13 14:12 ` L A Walsh
2018-04-13 18:29   ` Brian Inglis
2018-04-13 19:17     ` Corinna Vinschen
2018-04-13 17:22 ` Brian Inglis
2018-04-13 19:55   ` Achim Gratz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87in8xwre7.fsf@Rainer.invalid \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).