From 33ae45434d0ab1f7de365b9140ad4e4ffc34b8a2 Mon Sep 17 00:00:00 2001 From: Richard Bunt Date: Mon, 4 Dec 2023 14:23:17 +0000 Subject: gdb: Enable early init of thread pool size This commit enables the early initialization commands (92e4e97a9f5) to modify the number of threads used by gdb's thread pool. The motivation here is to prevent gdb from spawning a detrimental number of threads on many-core systems under environments with restrictive ulimits. With gdb before this commit, the thread pool takes the following sizes: 1. Thread pool size is initialized to 0. 2. After the maintenance commands are defined, the thread pool size is set to the number of system cores (if it has not already been set). 3. Using early initialization commands, the thread pool size can be changed using "maint set worker-threads". 4. After the first prompt, the thread pool size can be changed as in the previous step. Therefore after step 2. gdb has potentially launched hundreds of threads on a many-core system. After this change, step 2 and 3 are reversed so there is an opportunity to set the required number of threads without needing to default to the number of system cores first. There does exist a configure option (added in 261b07488b9) to disable multithreading, but this does not allow for an already deployed gdb to be configured. Additionally, the default number of worker threads is clamped at eight to control the number of worker threads spawned on many-core systems. This value was chosen as testing recorded on bugzilla issue 29959 indicates that parallel efficiency drops past this point. GDB built with GCC 13. No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel LLVM, NVHPC; Platforms: x86_64, aarch64. The scenario that interests me the most involves preventing GDB from spawning any worker threads at all. This was tested by counting the number of clones observed by strace: strace -e clone,clone3 gdb/gdb -q \ --early-init-eval-command="maint set worker-threads 0" \ -ex q ./gdb/gdb |& grep --count clone The new test relies on "gdb: install CLI uiout while processing early init files" developed by Andrew Burgess. This patch will need pushing prior to this change. The clamping was tested on machines with both 16 cores and a single core. "maint show worker-threads" correctly reported eight and one respectively. Approved-By: Tom Tromey --- gdbsupport/thread-pool.cc | 4 ++++ gdbsupport/thread-pool.h | 1 + 2 files changed, 5 insertions(+) (limited to 'gdbsupport') diff --git a/gdbsupport/thread-pool.cc b/gdbsupport/thread-pool.cc index bbe043d..0b11213 100644 --- a/gdbsupport/thread-pool.cc +++ b/gdbsupport/thread-pool.cc @@ -154,6 +154,7 @@ thread_pool::set_thread_count (size_t num_threads) { #if CXX_STD_THREAD std::lock_guard guard (m_tasks_mutex); + m_sized_at_least_once = true; /* If the new size is larger, start some new threads. */ if (m_thread_count < num_threads) @@ -197,6 +198,9 @@ thread_pool::set_thread_count (size_t num_threads) void thread_pool::do_post_task (std::packaged_task &&func) { + /* This assert is here to check that no tasks are posted to the pool between + its initialization and sizing. */ + gdb_assert (m_sized_at_least_once); std::packaged_task t (std::move (func)); if (m_thread_count != 0) diff --git a/gdbsupport/thread-pool.h b/gdbsupport/thread-pool.h index d5e1dc7..6959414 100644 --- a/gdbsupport/thread-pool.h +++ b/gdbsupport/thread-pool.h @@ -204,6 +204,7 @@ private: between the main thread and the worker threads. */ std::condition_variable m_tasks_cv; std::mutex m_tasks_mutex; + bool m_sized_at_least_once = false; #endif /* CXX_STD_THREAD */ }; -- cgit v1.1