From: Mark Geisert <mark@maxrnd.com>
To: cygwin-developers@cygwin.com
Subject: Re: Implement sched_[gs]etaffinity()
Date: Thu, 11 Apr 2019 20:52:00 -0000 [thread overview]
Message-ID: <Pine.BSF.4.63.1904111347400.10911@m0.truegem.net> (raw)
In-Reply-To: <20190411083745.GO4248@calimero.vinschen.de>
On Thu, 11 Apr 2019, Corinna Vinschen wrote:
> On Apr 11 10:25, Corinna Vinschen wrote:
>> Hi Mark,
>>
>> On Apr 10 21:21, Mark Geisert wrote:
>>> I've recently sent a patch to cygwin-patches that implements these
>>> Linux-specific functions. I used the following test program to debug and
>>> test the implementation. When the program is run, you can watch it migrate
>>> from CPU to CPU with Windows Task Manager.
>>>
>>> I've only tested on 64-bit Windows 7 so far. If the code (in the patch) is
>>> adequate I will supply another patch for doc updates, etc.
>>
>> Your patch is nicely done, but what about machines with more than 64
>> CPUs? Your patch only uses the standard API for up to 64 CPUs, so a
>> process can never use more than 64 CPUs or use CPUs from different CPU
>> groups. There was also the case of this weird machine Achim Gratz once
>> worked on, which had less than 64 CPUs but *still* used multiple CPU
>> groups under Windows, for some reason.
>>
>> Any chance you could update your patch to support this functionality?
>> For some info, see MSDN:
>>
>> https://docs.microsoft.com/en-us/windows/desktop/ProcThread/processor-groups
>>
>> Also, there's already some code in fhandler_proc.cc, function
>> format_proc_cpuinfo to handle CPU groups. You can use the
>> wincap.has_processor_groups() method to check if the system
>> supports CPU groups.
>
> Btw., Glibc's cpu_set_t supports up to 1024 CPUs. See
> https://sourceware.org/git/?p=glibc.git;a=blob;f=posix/bits/cpu-set.h
> This may be ok for the foreseable future, I guess.
Hi Corinna,
I will look into CPU group support; thanks for the pointers. I also need
to fix the assumption I made about which flavor of pid would be handed to
the functions.. they will be Cygwin pids but need conversion to Windows
pids internally.
..mark
next prev parent reply other threads:[~2019-04-11 20:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-11 4:21 Mark Geisert
2019-04-11 8:26 ` Corinna Vinschen
2019-04-11 8:38 ` Corinna Vinschen
2019-04-11 20:52 ` Mark Geisert [this message]
2019-04-12 7:46 ` Corinna Vinschen
2019-04-16 8:19 ` Mark Geisert
2019-04-16 10:45 ` Corinna Vinschen
2019-04-17 4:31 ` Mark Geisert
2019-04-17 7:57 ` Corinna Vinschen
2019-04-26 8:44 ` Mark Geisert
2019-04-26 8:53 ` Corinna Vinschen
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.BSF.4.63.1904111347400.10911@m0.truegem.net \
--to=mark@maxrnd.com \
--cc=cygwin-developers@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).