From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1033060AbdEYS1D (ORCPT ); Thu, 25 May 2017 14:27:03 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:34540 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S938742AbdEYS07 (ORCPT ); Thu, 25 May 2017 14:26:59 -0400 Date: Thu, 25 May 2017 11:26:55 -0700 From: Dmitry Torokhov To: "Luis R. Rodriguez" Cc: Tom Gundersen , Filipe Manana , "Paul E. McKenney" , "linux-doc@vger.kernel.org" , rgoldwyn@suse.com, hare , Jonathan Corbet , Linus Torvalds , linux-kselftest@vger.kernel.org, Andrew Morton , Dan Williams , Aaron Tomlin , rwright@hpe.com, Heinrich Schuchardt , Michal Marek , martin.wilck@suse.com, Rusty Russell , Jeff Mahoney , Ingo Molnar , Petr Mladek , Guenter Roeck , "Eric W. Biederman" , shuah@kernel.org, DSterba@suse.com, Kees Cook , Greg Kroah-Hartman , Josh Poimboeuf , Arnaldo Carvalho de Melo , Miroslav Benes , NeilBrown , "linux-kernel@vger.kernel.org" , David Miller , Jessica Yu , Subash Abhinov Kasiviswanathan Subject: Re: [PATCH 1/6] kmod: add dynamic max concurrent thread count Message-ID: <20170525182655.GD29859@dtor-ws> References: <20170519215829.GE19281@dtor-ws> <20170525162201.GV8951@wotan.suse.de> <20170525163857.GC26128@dtor-ws> <20170525173002.GC29859@dtor-ws> <20170525180603.GZ8951@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170525180603.GZ8951@wotan.suse.de> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 25, 2017 at 08:06:03PM +0200, Luis R. Rodriguez wrote: > On Thu, May 25, 2017 at 10:38:40AM -0700, Luis R. Rodriguez wrote: > > On Thu, May 25, 2017 at 10:30 AM, Dmitry Torokhov > > > There is > > > no slippery slope for systems to move away, no need to backport > > > anything. We seem to agree that a better solution is possible (throttle > > > number of concurrently running modprobes without killing requesters), > > > and with that solution the band-aid will no longer be needed. > > > > > > So please implement and post the proper fix for the issue. > > > > Alright, will do away with this patch and just go for the jugular of the issue. > > I gave this some more thought, even if we go with the throttling right away in > practice you'll end up with a dmesg notice of a throttle kicking in once you *do* So remove it. The warning was meaningful when we rejected requests, now it is not. > reach this. We are forcing only 50 concurrent threads and making this a static > limit with no good reason than 2.3.38 days evaluation from 16 years ago (2000). > If we throttle we are going to throttle with a 2.3.38 days limit. And you > advocate that ? Yes. Can you give me reason why slamming the system with more than 50 modprobes is a good idea in 4.12 days? Does the increased limit decreases boot time? By how much? -- Dmitry