package/openblas: allow disabling multithreading
PATCH 1/1 package/openblas: allow disabling multithreading
From: Thomas De Schampheleire <[email protected]>
Buildroot would automatically enable multithreading in OpenBLAS if the architecture supports it. However, one may want to avoid OpenBLAS creating threads itself and configure single-threaded operation. To accommodate this use case, add a config option for multithreading.
When multithreading is disabled, but OpenBLAS functions are called in the same application by multiple threads, then locking is mandatory. The USE_LOCKING flag was added in version 0.3.7 with following release note:
a new option USE_LOCKING was added to ensure thread safety when OpenBLAS itself is built without multithreading but will be called from multiple threads.
However, if one knows that OpenBLAS will only be called from single-threaded applications, then passing USE_LOCKING is not necessary, so make it a config option too.
---
This patch was sent earlier but had no response.
package/openblas/Config.in | 21 +++++++++++++++++++++ package/openblas/openblas.mk | 8 +++++++- 2 files changed, 28 insertions(+), 1 deletion(-)
package/openblas/Config.in +21 -0
@@ -73,4 +73,25 @@ config BR2_PACKAGE_OPENBLAS_TARGET string "OpenBLAS target CPU" default BR2_PACKAGE_OPENBLAS_DEFAULT_TARGET +config BR2_PACKAGE_OPENBLAS_USE_THREAD + bool "use multithreading" + default y + depends on BR2_TOOLCHAIN_HAS_THREADS + depends on !BR2_STATIC_LIBS + help + Tell OpenBLAS to use multithreading, by passing USE_THREAD=1. + +config BR2_PACKAGE_OPENBLAS_USE_LOCKING + bool "use locking" + default y + depends on BR2_TOOLCHAIN_HAS_THREADS + help + Tell OpenBLAS to use locking, by passing USE_LOCKING=1. + Locking is implicitly enabled when USE_THREAD=1, in which case + disabling this option will not have an effect. + However, if USE_THREAD=0 (i.e. OpenBLAS itself will run in + single-threaded mode) but an application makes OpenBLAS + function calls from multiple threads, then locking is + mandatory for correct operation. + endif
package/openblas/openblas.mk +7 -1
@@ -25,12 +25,18 @@ OPENBLAS_MAKE_OPTS += ONLY_CBLAS=1 endif # Enable/Disable multi-threading (not for static-only since it uses dlfcn.h) -ifeq ($(BR2_TOOLCHAIN_HAS_THREADS):$(BR2_STATIC_LIBS),y:) +ifeq ($(BR2_PACKAGE_OPENBLAS_USE_THREAD),y) OPENBLAS_MAKE_OPTS += USE_THREAD=1 else OPENBLAS_MAKE_OPTS += USE_THREAD=0 endif +ifeq ($(BR2_PACKAGE_OPENBLAS_USE_LOCKING),y) +OPENBLAS_MAKE_OPTS += USE_LOCKING=1 +else +OPENBLAS_MAKE_OPTS += USE_LOCKING=0 +endif + # We don't know if OpenMP is available or not, so disable OPENBLAS_MAKE_OPTS += USE_OPENMP=0
Signature · 1 line
2.26.2
PATCH 1/1 package/openblas: allow disabling multithreading
Hello Thomas,
package/openblas/Config.in config BR2_PACKAGE_OPENBLAS_TARGET · line 87
Quoted 12 lines · On Wed, 2 Dec 2020 15:50:24 +0100 Thomas De Schampheleire…
package/openblas/Config.in +12
-0+config BR2_PACKAGE_OPENBLAS_USE_THREAD + bool "use multithreading" + default y + depends on BR2_TOOLCHAIN_HAS_THREADS + depends on !BR2_STATIC_LIBS + help + Tell OpenBLAS to use multithreading, by passing USE_THREAD=1. + +config BR2_PACKAGE_OPENBLAS_USE_LOCKING + bool "use locking" + default y + depends on BR2_TOOLCHAIN_HAS_THREADS
Should this instead be:
depends on !BR2_PACKAGE_OPENBLAS_USE_THREAD
indeed, as you're explaining in the help text, when USE_THREAD=1, the USE_LOCKING option has no effect, as it is forcefully enabled.
And perhaps drop the "default y" ?
Thanks,
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
PATCH 1/1 package/openblas: allow disabling multithreading
Hi Thomas,
First of all, best wishes for 2021 and thanks for applying my patches recently!
El s?b, 2 ene 2021 a las 17:34, Thomas Petazzoni
(<[email protected]>) escribi?:
Quoted 21 lines
Hello Thomas,
package/openblas/Config.in config BR2_PACKAGE_OPENBLAS_TARGET · line 87
Quoted 12 lines · On Wed, 2 Dec 2020 15:50:24 +0100 Thomas De Schampheleire…
package/openblas/Config.in +12
-0+config BR2_PACKAGE_OPENBLAS_USE_THREAD + bool "use multithreading" + default y + depends on BR2_TOOLCHAIN_HAS_THREADS + depends on !BR2_STATIC_LIBS + help + Tell OpenBLAS to use multithreading, by passing USE_THREAD=1. + +config BR2_PACKAGE_OPENBLAS_USE_LOCKING + bool "use locking" + default y + depends on BR2_TOOLCHAIN_HAS_THREADSShould this instead be:
Quoted 4 lines
depends on !BR2_PACKAGE_OPENBLAS_USE_THREAD
indeed, as you're explaining in the help text, when USE_THREAD=1, the
USE_LOCKINGoption has no effect, as it is forcefully enabled.
We can indeed add this inverse dependency on BR2_PACKAGE_OPENBLAS_USE_THREAD, this is more clear. However, I think we also have to retain the dependency on BR2_TOOLCHAIN_HAS_THREADS, right? Because if there is no thread support, it does not make sense to lock.
If only depending on !BR2_PACKAGE_OPENBLAS_USE_THREAD, then the USE_LOCKING option becomes visible if !BR2_TOOLCHAIN_HAS_THREADS . Right?
Quoted 2 lines
And perhaps drop the "default y" ?
I added 'default y' because the introduction of USE_LOCKING in openblas actually lead to a regression if you were using it in single-threaded mode from a multi-threaded application. The regression is only at run-time and causes incorrect math results in some cases (ugh!).
So, the 'default y' would help existing users in this situation when upgrading Buildroot and its contained openblas.
We could remove the 'default y' too. In my own repo I can make sure to enable USE_LOCKING explicitly. This may be fine if we assume there are few users that use openblas, and even fewer that use it in single-threaded mode from a multithreaded application.
Thanks,
Thomas
PATCH 1/1 package/openblas: allow disabling multithreading
Quoted 1 line · On Tue, 5 Jan 2021 15:19:22 +0100 Thomas De Schampheleire…
First of all, best wishes for 2021 and thanks for applying my patches recently!
Best wishes to you as well!
Quoted 7 lines
Quoted 6 lines
Should this instead be:
depends on !BR2_PACKAGE_OPENBLAS_USE_THREAD
indeed, as you're explaining in the help text, when USE_THREAD=1, the
USE_LOCKINGoption has no effect, as it is forcefully enabled.
Quoted 8 lines
We can indeed add this inverse dependency on
BR2_PACKAGE_OPENBLAS_USE_THREAD, this is more clear. However, I think we also have to retain the dependency onBR2_TOOLCHAIN_HAS_THREADS, right? Because if there is no thread support, it does not make sense to lock.
If only depending on !BR2_PACKAGE_OPENBLAS_USE_THREAD, then theUSE_LOCKINGoption becomes visible if !BR2_TOOLCHAIN_HAS_THREADS . Right?
Right, seems a good idea.
Quoted 10 lines
Quoted 1 line
And perhaps drop the "default y" ?
I added 'default y' because the introduction of
USE_LOCKINGin openblas actually lead to a regression if you were using it in single-threaded mode from a multi-threaded application. The regression is only at run-time and causes incorrect math results in some cases (ugh!).
So, the 'default y' would help existing users in this situation when upgrading Buildroot and its contained openblas.
Quoted 4 lines
We could remove the 'default y' too. In my own repo I can make sure to enable
USE_LOCKINGexplicitly. This may be fine if we assume there are few users that use openblas, and even fewer that use it in single-threaded mode from a multithreaded application.
Right, fair enough with "default y" then.
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com