Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1645922
| From | Dmitry Torokhov <dmitry.torokhov@gmail.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 1/6] kmod: add dynamic max concurrent thread count |
| Date | 2017-05-19 22:50 +0200 |
| Message-ID | <tIX0u-7xL-13@gated-at.bofh.it> (permalink) |
| References | <tIGM1-4u0-5@gated-at.bofh.it> <tIGM2-4u0-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, May 18, 2017 at 08:24:39PM -0700, Luis R. Rodriguez wrote: > We currently statically limit the number of modprobe threads which > we allow to run concurrently to 50. As per Keith Owens, this was a > completely arbitrary value, and it was set in the 2.3.38 days [0] > over 16 years ago in year 2000. > > Although we haven't yet hit our lower limits, experimentation [1] > shows that when and if we hit this limit in the worst case, will be > fatal -- consider get_fs_type() failures upon mount on a system which > has many partitions, some of which might even be with the same > filesystem. Its best to be prudent and increase and set this > value to something more sensible which ensures we're far from hitting > the limit and also allows default build/user run time override. > > The worst case is fatal given that once a module fails to load there > is a period of time during which subsequent request for the same module > will fail, so in the case of partitions its not just one request that > could fail, but whole series of partitions. This later issue of a > module request failure domino effect can be addressed later, but > increasing the limit to something more meaninful should at least give us > enough cushion to avoid this for a while. > > Set this value up with a bit more meaninful modern limits: > > Bump this up to 64 max for small systems (CONFIG_BASE_SMALL) > Bump this up to 128 max for larger systems (!CONFIG_BASE_SMALL) > > Also allow the default max limit to be further fine tuned at compile > time and at initialization at run time at boot up using the kernel > parameter: max_modprobes. > > [0] https://git.kernel.org/cgit/linux/kernel/git/history/history.git/commit/?id=ab1c4ec7410f6ec64e1511d1a7d850fc99c09b44 > [1] https://github.com/mcgrof/test_request_module If we actually run into this issue, instead of slamming the system with bazillion concurrent requests, can we wait for the other modprobes to finish and then continue? Thanks. -- Dmitry
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 0/6] kmod: few simple enhancements "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-05-19 05:30 +0200
[PATCH 1/6] kmod: add dynamic max concurrent thread count "Luis R. Rodriguez" <mcgrof@kernel.org> - 2017-05-19 05:30 +0200
Re: [PATCH 1/6] kmod: add dynamic max concurrent thread count Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-05-19 22:50 +0200
Re: [PATCH 1/6] kmod: add dynamic max concurrent thread count Dmitry Torokhov <dmitry.torokhov@gmail.com> - 2017-05-20 00:00 +0200
csiph-web