From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751425AbdFZKD5 (ORCPT ); Mon, 26 Jun 2017 06:03:57 -0400 Received: from mx2.suse.de ([195.135.220.15]:50192 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751463AbdFZKDs (ORCPT ); Mon, 26 Jun 2017 06:03:48 -0400 Date: Mon, 26 Jun 2017 12:03:30 +0200 From: Petr Mladek To: "Luis R. Rodriguez" Cc: akpm@linux-foundation.org, jeyu@redhat.com, shuah@kernel.org, rusty@rustcorp.com.au, ebiederm@xmission.com, dmitry.torokhov@gmail.com, acme@redhat.com, corbet@lwn.net, josh@joshtriplett.org, martin.wilck@suse.com, mmarek@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, alan@linux.intel.com, tytso@mit.edu, gregkh@linuxfoundation.org, torvalds@linux-foundation.org, linux-kselftest@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 4/4] kmod: throttle kmod thread limit Message-ID: <20170626100330.GH1538@pathway.suse.cz> References: <20170526001630.19203-1-mcgrof@kernel.org> <20170526211228.27764-1-mcgrof@kernel.org> <20170526211228.27764-5-mcgrof@kernel.org> <20170622151936.GE1538@pathway.suse.cz> <20170623161619.GL21846@wotan.suse.de> <20170623175611.GP21846@wotan.suse.de> <20170623191637.GT21846@wotan.suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170623191637.GT21846@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 Fri 2017-06-23 21:16:37, Luis R. Rodriguez wrote: > On Fri, Jun 23, 2017 at 07:56:11PM +0200, Luis R. Rodriguez wrote: > > On Fri, Jun 23, 2017 at 06:16:19PM +0200, Luis R. Rodriguez wrote: > > > On Thu, Jun 22, 2017 at 05:19:36PM +0200, Petr Mladek wrote: > > > > On Fri 2017-05-26 14:12:28, Luis R. Rodriguez wrote: > > > > > --- a/kernel/kmod.c > > > > > +++ b/kernel/kmod.c > > > > > @@ -178,6 +175,7 @@ int __request_module(bool wait, const char *fmt, ...) > > > > > ret = call_modprobe(module_name, wait ? UMH_WAIT_PROC : UMH_WAIT_EXEC); > > > > > > > > > > atomic_inc(&kmod_concurrent_max); > > > > > + wake_up_all(&kmod_wq); > > > > > > > > Does it make sense to wake up all waiters when we released the resource > > > > only for one? IMHO, a simple wake_up() should be here. > > > > > > Then we should wake_up() also on failure, otherwise we have the potential > > > to not wake some in a proper time. > > > > I checked and it turns out we have no error paths after we consume a kmod > > ticket, if you will. Once we bump with atomic_dec_if_positive() we assume > > we're moving forward with an attempt, and the only failure path is already > > bundled with a wake at the end of the __request_module() call. > > > > Then the next question would be *who* exactly gets woken up next if we just > > use wake_up() ? The common core wake up code varies depending on use and > > all this reminded me of the complexity we just don't need, so I have now > > converted to use swait. swait uses list_add() if empty and then iterates > > with list_first_entry() on wakeup, so that should get the first item added > > to the wait list. > > > > Works with me. Will run a test a before v4 is sent, but since only 2 patches > > are modified will only send a respective update for these 2 patches. > > Alright, this worked out well! Its just a tiny bit slower on test cases 0008 > and 0009 (few seconds) but that's fine, its natural due to the lack of the > swake_up_all(). This is interesting. I guess that it was faster with swake_up_all() because it worked as a speculative pre-wake. I mean that it takes some time between adding a process into run-queue and really running it. IMHO, swake_up_all() caused that __request_module() callers were more often really running and trying to pass that atomic_dec_if_positive(&kmod_concurrent_max) >= 0). Best Regards, Petr