1
0
mirror of https://github.com/RPCS3/llvm-mirror.git synced 2025-01-31 20:51:52 +01:00

32 Commits

Author SHA1 Message Date
Alexandre Ganea
11bbe8413e Re-land [Support] On Windows, take the affinity mask into account
The number of hardware threads available to a ThreadPool can be limited if setting an affinity mask.
For example:

    > start /B /AFFINITY 0xF lld-link.exe ...

Would let LLD only use 4 hyper-threads.

Previously, there was an outstanding issue on Windows Server 2019 on dual-CPU machines, which was preventing from using both CPU sockets. In normal conditions, when no affinity mask was set, ProcessorGroup::AllThreads was different from ProcessorGroup::UsableThreads. The previous code in llvm/lib/Support/Windows/Threading.inc L201 was improperly assuming those two values to be equal, and consequently was limiting the execution to only one CPU socket.

Differential Revision: https://reviews.llvm.org/D92419
2021-01-14 17:03:22 -05:00
Alexandre Ganea
fa81c13e42 Revert "[Support] On Windows, take the affinity mask into account"
This reverts commit 336ab2d51dfdd5ca09c2a9c506453db4fe653584.
2021-01-13 21:34:54 -05:00
Alexandre Ganea
228337357d [Support] On Windows, take the affinity mask into account
The number of hardware threads available to a ThreadPool can be limited if setting an affinity mask.
For example:

> start /B /AFFINITY 0xF lld-link.exe ...

Would let LLD only use 4 hyper-threads.

Previously, there was an outstanding issue on Windows Server 2019 on dual-CPU machines, which was preventing from using both CPU sockets. In normal conditions, when no affinity mask was set, ProcessorGroup::AllThreads was different from ProcessorGroup::UsableThreads. The previous code in llvm/lib/Support/Windows/Threading.inc L201 was improperly assuming those two values to be equal, and consequently was limiting the execution to only one CPU socket.

Differential Revision: https://reviews.llvm.org/D92419
2021-01-13 21:00:09 -05:00
Lang Hames
4b2ec2e0f8 Revert "[Support] Use unique_function rather than std::function for ThreadPool TaskTy."
This reverts commit d9c8b0256cfc673c2413b13993c9440be598818f.

Some MSVC std::packaged_task implementations are not compatible with move-only types.
This caused failures on some of the Windows builders (e.g.
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/69412).

Reverting until I can come up with a workaround.
2020-09-10 11:53:09 -07:00
Lang Hames
12a4a51f26 [Support] Use unique_function rather than std::function for ThreadPool TaskTy.
This will allow non-copyable function objects (e.g. lambdas that capture
unique_ptrs) to be used with ThreadPool.

Differential Revision: https://reviews.llvm.org/D87467
2020-09-10 10:46:46 -07:00
Simon Pilgrim
f5fa275b44 Revert rGf0bab7875e78e01c149d12302dcc4b6d4c43e25c - "Triple.h - reduce Twine.h include to forward declarations. NFC."
This causes ICEs on the clang-ppc64be buildbots and I've limited ability to triage the problem.
2020-06-26 14:46:40 +01:00
Simon Pilgrim
efd7ae7bbc Triple.h - reduce Twine.h include to forward declarations. NFC.
Move include down to a number of other files that had an implicit dependency on the Twine class.
2020-06-26 13:06:57 +01:00
Alexandre Ganea
a35f34551e [Support] Fix fragile ThreadPool test
The test ThreadPoolTest.AllThreads_UseAllRessources occasionally fails on the bots: http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/32015/steps/test-check-all/logs/FAIL%3A%20LLVM-Unit%3A%3AThreadPoolTest.AllThreads_UseAllRessources

This is because jobs were executed too fast on the first CPU socket, and never manage to reach the second CPU socket.

Differential Revision: https://reviews.llvm.org/D78832
2020-04-25 15:06:21 -04:00
Alexandre Ganea
2a2b6dfe5d [Support] In tests, fix warning: variable ‘Threads’ set but not used 2020-02-15 09:05:01 -05:00
Alexandre Ganea
ae05eb086d [Support] On Windows, ensure hardware_concurrency() extends to all CPU sockets and all NUMA groups
The goal of this patch is to maximize CPU utilization on multi-socket or high core count systems, so that parallel computations such as LLD/ThinLTO can use all hardware threads in the system. Before this patch, on Windows, a maximum of 64 hardware threads could be used at most, in some cases dispatched only on one CPU socket.

== Background ==
Windows doesn't have a flat cpu_set_t like Linux. Instead, it projects hardware CPUs (or NUMA nodes) to applications through a concept of "processor groups". A "processor" is the smallest unit of execution on a CPU, that is, an hyper-thread if SMT is active; a core otherwise. There's a limit of 32-bit processors on older 32-bit versions of Windows, which later was raised to 64-processors with 64-bit versions of Windows. This limit comes from the affinity mask, which historically is represented by the sizeof(void*). Consequently, the concept of "processor groups" was introduced for dealing with systems with more than 64 hyper-threads.

By default, the Windows OS assigns only one "processor group" to each starting application, in a round-robin manner. If the application wants to use more processors, it needs to programmatically enable it, by assigning threads to other "processor groups". This also means that affinity cannot cross "processor group" boundaries; one can only specify a "preferred" group on start-up, but the application is free to allocate more groups if it wants to.

This creates a peculiar situation, where newer CPUs like the AMD EPYC 7702P (64-cores, 128-hyperthreads) are projected by the OS as two (2) "processor groups". This means that by default, an application can only use half of the cores. This situation could only get worse in the years to come, as dies with more cores will appear on the market.

== The problem ==
The heavyweight_hardware_concurrency() API was introduced so that only *one hardware thread per core* was used. Once that API returns, that original intention is lost, only the number of threads is retained. Consider a situation, on Windows, where the system has 2 CPU sockets, 18 cores each, each core having 2 hyper-threads, for a total of 72 hyper-threads. Both heavyweight_hardware_concurrency() and hardware_concurrency() currently return 36, because on Windows they are simply wrappers over std:🧵:hardware_concurrency() -- which can only return processors from the current "processor group".

== The changes in this patch ==
To solve this situation, we capture (and retain) the initial intention until the point of usage, through a new ThreadPoolStrategy class. The number of threads to use is deferred as late as possible, until the moment where the std::threads are created (ThreadPool in the case of ThinLTO).

When using hardware_concurrency(), setting ThreadCount to 0 now means to use all the possible hardware CPU (SMT) threads. Providing a ThreadCount above to the maximum number of threads will have no effect, the maximum will be used instead.
The heavyweight_hardware_concurrency() is similar to hardware_concurrency(), except that only one thread per hardware *core* will be used.

When LLVM_ENABLE_THREADS is OFF, the threading APIs will always return 1, to ensure any caller loops will be exercised at least once.

Differential Revision: https://reviews.llvm.org/D71775
2020-02-14 10:24:22 -05:00
Simon Pilgrim
ff4f330212 Fix uninitialized variable warning. NFC. 2019-11-18 13:26:51 +00:00
Chandler Carruth
ae65e281f3 Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636
2019-01-19 08:50:56 +00:00
Zachary Turner
4453f047a5 Revert "Enable ThreadPool to queue tasks that return values."
This is failing to compile when LLVM_ENABLE_THREADS is false,
and the fix is not immediately obvious, so reverting while I look
into it.

llvm-svn: 334658
2018-06-13 21:24:19 +00:00
Zachary Turner
1f1b9ca909 Enable ThreadPool to support tasks that return values.
Previously ThreadPool could only queue async "jobs", i.e. work
that was done for its side effects and not for its result.  It's
useful occasionally to queue async work that returns a value.
From an API perspective, this is very intuitive.  The previous
API just returned a shared_future<void>, so all we need to do is
make it return a shared_future<T>, where T is the type of value
that the operation returns.

Making this work required a little magic, but ultimately it's not
too bad.  Instead of keeping a shared queue<packaged_task<void()>>
we just keep a shared queue<unique_ptr<TaskBase>>, where TaskBase
is a class with a pure virtual execute() method, then have a
templated derived class that stores a packaged_task<T()>.  Everything
else works out pretty cleanly.

Differential Revision: https://reviews.llvm.org/D48115

llvm-svn: 334643
2018-06-13 19:29:16 +00:00
Malcolm Parsons
26eb6a0783 Remove unused lambda captures. NFC
llvm-svn: 291916
2017-01-13 17:12:16 +00:00
Davide Italiano
24691c7655 [ThreadPool] Rollback recent changes until I figure out the breakage.
llvm-svn: 288018
2016-11-28 09:17:12 +00:00
Davide Italiano
ada55c7225 [ThreadPool] Simplify the interface. NFCI.
The callers don't use the return value. Found by Michael
Spencer.

llvm-svn: 288016
2016-11-28 08:53:41 +00:00
David Majnemer
85242fb9f9 Use the range variant of find instead of unpacking begin/end
If the result of the find is only used to compare against end(), just
use is_contained instead.

No functionality change is intended.

llvm-svn: 278433
2016-08-11 22:21:41 +00:00
Eli Friedman
d8092c740d Fix deadlock in ThreadPool unittest.
(Yes, this only deadlocks on a computer with a single core; I'm using
a virtual machine.)

llvm-svn: 271855
2016-06-05 21:15:46 +00:00
Mehdi Amini
a61b37683e ThreadPool unittests: do not hold mutex when calling condition_variable:notify()
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 256111
2015-12-19 22:56:24 +00:00
Vedant Kumar
f2199d9e59 [unittests] ThreadPool: Remove redundant loop, NFC
llvm-svn: 256097
2015-12-19 09:54:27 +00:00
Vedant Kumar
1060fa635e [unittests] ThreadPool: Guard updates to MainThreadReady
llvm-svn: 256096
2015-12-19 09:49:09 +00:00
Mehdi Amini
6c98bbb0ba ThreadPool unittest: reimplement concurrency test, deterministically this time.
Follow-up to r256056.

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 256087
2015-12-19 05:12:07 +00:00
Teresa Johnson
1492e65cc6 Remove possibility of failures to due race in ThreadPool unittest
Remove all checks that required main thread to run faster than tasks in
ThreadPool, and yields which are now unnecessary. This should fix some
bot failures.

llvm-svn: 256056
2015-12-18 22:59:35 +00:00
Mehdi Amini
d6deaf29d7 Mark ThreadPool unittests as unsupported on PowerPC64
Bots are crashing unexpectingly, see: https://llvm.org/bugs/show_bug.cgi?id=25829

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 255633
2015-12-15 09:10:28 +00:00
Mehdi Amini
b327be8926 ThreadPool unittest: add a rough mechanism to mark UNSUPPORTED on a given platform
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 255632
2015-12-15 09:10:25 +00:00
Teresa Johnson
ff38b7b132 Fix template parameter pack handling in ThreadPool
Fixes passing of template parameter pack via std::forward and add
unittest.

llvm-svn: 255617
2015-12-15 04:44:02 +00:00
Mehdi Amini
54fc055738 Add a C++11 ThreadPool implementation in LLVM
This is a very simple implementation of a thread pool using C++11
thread. It accepts any std::function<void()> for asynchronous
execution. Individual task can be synchronize using the returned
future, or the client can block on the full queue completion.

In case LLVM is configured with Threading disabled, it falls back
to sequential execution using std::async with launch:deferred.

This is intended to support parallelism for ThinLTO processing in
linker plugin, but is generic enough for any other uses.

This is a recommit of r255444 ; trying to workaround a bug in the
MSVC 2013 standard library. I think I was hit by:

 http://connect.microsoft.com/VisualStudio/feedbackdetail/view/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable

Recommit of r255589, trying to please g++ as well.

Differential Revision: http://reviews.llvm.org/D15464

From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8>
llvm-svn: 255593
2015-12-15 00:59:19 +00:00
Mehdi Amini
5acecbc1ec Revert "Add a C++11 ThreadPool implementation in LLVM"
This reverts commit r255589. Breaks g++

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 255591
2015-12-15 00:42:44 +00:00
Mehdi Amini
dbdd929681 Add a C++11 ThreadPool implementation in LLVM
This is a very simple implementation of a thread pool using C++11
thread. It accepts any std::function<void()> for asynchronous
execution. Individual task can be synchronize using the returned
future, or the client can block on the full queue completion.

In case LLVM is configured with Threading disabled, it falls back
to sequential execution using std::async with launch:deferred.

This is intended to support parallelism for ThinLTO processing in
linker plugin, but is generic enough for any other uses.

This is a recommit of r255444 ; trying to workaround a bug in the
MSVC 2013 standard library. I think I was hit by:

 http://connect.microsoft.com/VisualStudio/feedbackdetail/view/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable

Differential Revision: http://reviews.llvm.org/D15464

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 255589
2015-12-15 00:38:05 +00:00
Nico Weber
c244167f92 Revert r255444.
It doesn't build on Windows and broke the Windows LLD and LLDB bots:
http://lab.llvm.org:8011/builders/lld-x86_64-win7/builds/27693/steps/build_Lld/logs/stdio
http://lab.llvm.org:8011/builders/lldb-x86-windows-msvc/builds/13468/steps/build/logs/stdio

llvm-svn: 255446
2015-12-13 04:14:39 +00:00
Mehdi Amini
865fad06c6 Add a C++11 ThreadPool implementation in LLVM
This is a very simple implementation of a thread pool using C++11
thread. It accepts any std::function<void()> for asynchronous
execution. Individual task can be synchronize using the returned
future, or the client can block on the full queue completion.

In case LLVM is configured with Threading disabled, it falls back
to sequential execution using std::async with launch:deferred.

This is intended to support parallelism for ThinLTO processing in
linker plugin, but is generic enough for any other uses.

Differential Revision: http://reviews.llvm.org/D15464

From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 255444
2015-12-12 22:55:25 +00:00