kernel: Fix boot of amrsr target in qemu
The bootup of the armsr target sometimes failed like this: ``` [ 0.762283] NET: Registered PF_INET6 protocol family [ 0.791987] workqueue: Failed to create a worker thread: -EAGAIN [ 0.801986] workqueue: Failed to create a rescuer kthread for wq "mld": -EAGAIN [ 0.964017] NET: Unregistered PF_INET6 protocol family ``` Increase the maximum number of threads the kernel allows. Link: https://github.com/openwrt/openwrt/pull/19376 Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
This commit is contained in:
parent
01a9a27dfa
commit
c5330bdf7e
2 changed files with 74 additions and 0 deletions
|
@ -0,0 +1,37 @@
|
||||||
|
From a22c4c7bbfad3e93e717e16f6faf343259add27a Mon Sep 17 00:00:00 2001
|
||||||
|
From: Hauke Mehrtens <hauke@hauke-m.de>
|
||||||
|
Date: Fri, 27 Jun 2025 11:09:04 +0100
|
||||||
|
Subject: [PATCH v2] kernel/fork: Increase minimum number of allowed threads
|
||||||
|
|
||||||
|
A modern Linux system creates much more than 20 threads at bootup.
|
||||||
|
When I booted up OpenWrt in qemu the system sometimes failed to boot up
|
||||||
|
when it wanted to create the 419th thread. The VM had 128MB RAM and the
|
||||||
|
calculation in set_max_threads() calculated that max_threads should be
|
||||||
|
set to 419. When the system booted up it tried to notify the user space
|
||||||
|
about every device it created because CONFIG_UEVENT_HELPER was set and
|
||||||
|
used. I counted 1299 calls to call_usermodehelper_setup(), all of
|
||||||
|
them try to create a new thread and call the userspace hotplug script in
|
||||||
|
it.
|
||||||
|
|
||||||
|
This fixes bootup of Linux on systems with low memory.
|
||||||
|
|
||||||
|
I saw the problem with qemu 10.0.2 using these commands:
|
||||||
|
qemu-system-aarch64 -machine virt -cpu cortex-a57 -nographic
|
||||||
|
|
||||||
|
Cc: stable@vger.kernel.org
|
||||||
|
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
|
||||||
|
---
|
||||||
|
kernel/fork.c | 2 +-
|
||||||
|
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||||
|
|
||||||
|
--- a/kernel/fork.c
|
||||||
|
+++ b/kernel/fork.c
|
||||||
|
@@ -123,7 +123,7 @@
|
||||||
|
/*
|
||||||
|
* Minimum number of threads to boot the kernel
|
||||||
|
*/
|
||||||
|
-#define MIN_THREADS 20
|
||||||
|
+#define MIN_THREADS 600
|
||||||
|
|
||||||
|
/*
|
||||||
|
* Maximum number of threads
|
|
@ -0,0 +1,37 @@
|
||||||
|
From a22c4c7bbfad3e93e717e16f6faf343259add27a Mon Sep 17 00:00:00 2001
|
||||||
|
From: Hauke Mehrtens <hauke@hauke-m.de>
|
||||||
|
Date: Fri, 27 Jun 2025 11:09:04 +0100
|
||||||
|
Subject: [PATCH v2] kernel/fork: Increase minimum number of allowed threads
|
||||||
|
|
||||||
|
A modern Linux system creates much more than 20 threads at bootup.
|
||||||
|
When I booted up OpenWrt in qemu the system sometimes failed to boot up
|
||||||
|
when it wanted to create the 419th thread. The VM had 128MB RAM and the
|
||||||
|
calculation in set_max_threads() calculated that max_threads should be
|
||||||
|
set to 419. When the system booted up it tried to notify the user space
|
||||||
|
about every device it created because CONFIG_UEVENT_HELPER was set and
|
||||||
|
used. I counted 1299 calls to call_usermodehelper_setup(), all of
|
||||||
|
them try to create a new thread and call the userspace hotplug script in
|
||||||
|
it.
|
||||||
|
|
||||||
|
This fixes bootup of Linux on systems with low memory.
|
||||||
|
|
||||||
|
I saw the problem with qemu 10.0.2 using these commands:
|
||||||
|
qemu-system-aarch64 -machine virt -cpu cortex-a57 -nographic
|
||||||
|
|
||||||
|
Cc: stable@vger.kernel.org
|
||||||
|
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
|
||||||
|
---
|
||||||
|
kernel/fork.c | 2 +-
|
||||||
|
1 file changed, 1 insertion(+), 1 deletion(-)
|
||||||
|
|
||||||
|
--- a/kernel/fork.c
|
||||||
|
+++ b/kernel/fork.c
|
||||||
|
@@ -115,7 +115,7 @@
|
||||||
|
/*
|
||||||
|
* Minimum number of threads to boot the kernel
|
||||||
|
*/
|
||||||
|
-#define MIN_THREADS 20
|
||||||
|
+#define MIN_THREADS 600
|
||||||
|
|
||||||
|
/*
|
||||||
|
* Maximum number of threads
|
Loading…
Reference in a new issue