[LINUX] About the upper limit of threads-max

threads-max is the maximum number of threads that the kernel can use at one time throughout the system The kernel parameter to set. The value that can be set for this parameter is significantly higher than MAX_THREADS. Until recently, there was a regression that only small values could be set. Specifically, from kernel-4.0 (April 2015) to kernel-5.4-rc3 (October 2019) Such a situation continued. This has been fixed in kernel-5.4.

Old-fashioned behavior (tested in 4GB RAM environment) # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 1073741823

kernel with regression (tested in 4GB RAM environment) # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 31348

The upper limit that can be set in the kernel is automatically set according to the size of the real memory. It was a noisy operation that made me decide. If the application does not adjust this parameter It would have been a problem in an environment where it couldn't work.

An email like this was sent to LKML and the discussion started. .. .. .. https://lkml.org/lkml/2019/9/17/294 Hi, I have just stmbled over 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits") and I am really wondering what is the motivation behind the patch. We've had a customer noticing the threads_max autoscaling differences btween 3.12 and 4.4 kernels and wanted to override the auto tuning from the userspace, just to find out that this is not possible.

Why do we override user admin like that? I find it quite dubious to be honest. Especially when the auto-tunning is just a very rough estimation and it seems quite arbitrary.

Free translation: "My customer rewrites the value entered by threads-max with auto tuning working. I found it working, but what does patch 16db3d3f1170 mean? "

Developer replies https://lkml.org/lkml/2019/9/17/570 set_max_threads() sets the upper limit (max_threads_suggested) for threads such that at a maximum 1/8th of the total memory can be occupied by the thread's administrative data (of size THREADS_SIZE). On my 32 GiB system this results in 254313 threads.

With patch 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits") a user cannot set an arbitrarily high number for /proc/sys/kernel/threads-max which could lead to a system stalling because the thread headers occupy all the memory.

Free translation: set_max_threads () limits the thread limit to 1/8 of RAM. It's no longer possible for the system to stall by filling memory with thread data!

SUSE engineers answer and say https://lkml.org/lkml/2019/9/17/589 This is still a decision of the admin to make. You can consume the memory by other means and that is why we have measures in place. E.g. memcg accounting.

Free translation: That's what the administrator decides. That's why there are measurement tools like memcg.

You do not change the software to overcome artificial bounds based on guessing.

Free translation: Do not make any changes that set an upper limit by arbitrary guess.

Another engineer https://lkml.org/lkml/2019/9/17/705 a) The logic to set the default number of threads in a system has not changed since 2.6.12-rc2 (the start of the git history).

Free translation: The behavior that hasn't changed since 2.6.12-rc2, which I started managing with git, has changed due to the patch.

Limiting threads_max to the auto-scaling value is a regression.

Free translation: It is Regression that adjusts the input value of threads-max to auto-scaling value.

https://lkml.org/lkml/2019/9/19/113 Any take on this Heinrich? If there really is not strong reasoning about the restricting user input then I will suggest reverting 16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")

Free translation: We propose to revert the patch.

Andrew Morton comes out and says a word https://lkml.org/lkml/2019/9/19/748 I agree, based on what I'm seeing in this thread.

Free translation: I saw this thread, but I agree with reverting.

Thus, b0f53dbc4bc4c371f38 (kernel / sysctl.c: do not override max_s A patch called provided by userspace) has entered the mainline kernel The patch was backported to the stable relase below.

Mainline 5.4 stable 5.3.7 stable 4.19.80 stable 4.14.150 stable 4.9.197 stable 4.4.197

In these kernel versions, # echo 0x3fffffff > /proc/sys/vm/threads-max # cat /proc/sys/vm/threads-max 1073741823 It has returned to the old operation.

With the patch backported to Stable relase, the Fedora 31 kernel also has a thread-max fix.

that's all

Recommended Posts

About the upper limit of threads-max
About the ease of Python
About the components of Luigi
About the features of Python
About the return value of the histogram.
About the basic type of Go
About the behavior of yield_per of SqlAlchemy
About the size of matplotlib points
About the basics list of Python basics
About the behavior of enable_backprop of Chainer v2
About the virtual environment of python version 3.7
About the arguments of the setup function of PyCaret
About the Normal Equation of Linear Regression
About the test
About the queue
About the accuracy of Archimedean circle calculation method
About the behavior of copy, deepcopy and numpy.copy
About the X-axis notation of Matplotlib bar graphs
About the processing speed of SVM (SVC) of scikit-learn
A note about the python version of python virtualenv
About the development contents of machine learning (Example)
[Note] About the role of underscore "_" in Python
About the behavior of Model.get_or_create () of peewee in Python
About the behavior of Queue during parallel processing
About the * (asterisk) argument of python (and itertools.starmap)
Set an upper limit on the number of recursive function iterations in Python
The beginning of cif2cell
A memorandum about the warning of the pylint output result
About all of numpy
The meaning of self
About MultiIndex of pandas
the zen of Python
Think about the next generation of Rack and WSGI
About testing in the implementation of machine learning models
About the inefficiency of data transfer in luigi on-memory
The story of sys.path.append ()
Referencing and changing the upper bound of Python recursion
About the Unfold function
About the service command
About the uncluttered arrangement in the import order of flake8
A story about changing the master name of BlueZ
About variable of chainer
About the confusion matrix
About the Visitor pattern
Personal notes about the integration of vscode and anaconda
A reminder about the implementation of recommendations in Python
Revenge of the Types: Revenge of types
Think about the analysis environment (Part 1: Overview) * As of January 2017
About the camera change event of Google Maps Android API
About the garbled Japanese part of pandas-profiling in Jupyter notebook
Tank game made with python About the behavior of tanks
A memo about the behavior of bowtie2 during multiple hits
[Linux] [kernel module] Specify / limit the execution CPU of kthread
Align the version of chromedriver_binary
About max_iter of LogisticRegression () of scikit-learn
Scraping the result of "Schedule-kun"
Security group rule upper limit
10. Counting the number of lines
The story of building Zabbix 4.4
Towards the retirement of Python2
[Apache] The story of prefork