Re: [PATCH 1/6] kmod: add dynamic max concurrent thread count

From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "Luis R. Rodriguez" <mcgrof@kernel.org>
Cc: shuah@kernel.org, jeyu@redhat.com, rusty@rustcorp.com.au,
	ebiederm@xmission.com, acme@redhat.com, corbet@lwn.net,
	martin.wilck@suse.com, mmarek@suse.com, pmladek@suse.com,
	hare@suse.com, rwright@hpe.com, jeffm@suse.com, DSterba@suse.com,
	fdmanana@suse.com, neilb@suse.com, linux@roeck-us.net,
	rgoldwyn@suse.com, subashab@codeaurora.org, xypron.glpk@gmx.de,
	keescook@chromium.org, atomlin@redhat.com, mbenes@suse.cz,
	paulmck@linux.vnet.ibm.com, dan.j.williams@intel.com,
	jpoimboe@redhat.com, davem@davemloft.net, mingo@redhat.com,
	akpm@linux-foundation.org, torvalds@linux-foundation.org,
	gregkh@linuxfoundation.org, linux-kselftest@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] kmod: add dynamic max concurrent thread count
Date: Fri, 19 May 2017 13:44:57 -0700	[thread overview]
Message-ID: <20170519204457.GC19281@dtor-ws> (raw)
In-Reply-To: <20170519032444.18416-2-mcgrof@kernel.org>

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