Message ID | 20211102105310.22809-1-michael.tremer@ipfire.org |
---|---|
State | Accepted |
Commit | 7091738a5c3c5a95d358f5da498493914eeaf688 |
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4Hk6FS36Mvz3wb6 for <patchwork@web04.haj.ipfire.org>; Tue, 2 Nov 2021 10:53:16 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4Hk6FR3gNLzTm; Tue, 2 Nov 2021 10:53:15 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4Hk6FR2Xlwz2yrp; Tue, 2 Nov 2021 10:53:15 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4Hk6FQ1ZKhz2xFK for <development@lists.ipfire.org>; Tue, 2 Nov 2021 10:53:14 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4Hk6FP3BS0zTm; Tue, 2 Nov 2021 10:53:13 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1635850393; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=4XwBvm00ahWS2h4/qBiGUzORvOgY+vmSLonfSWeoV+c=; b=a1f4APrutbJ4zYDl61LUdlyDxPq+UdP/WE3avQyer3Jjd/tNw5eKT+DnulZrzZI1VTgUa2 I+8lnrbBatn8r5Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1635850393; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=4XwBvm00ahWS2h4/qBiGUzORvOgY+vmSLonfSWeoV+c=; b=jI1ZQ6C+0ujMILFEsTJZvKZQuMwSZdeETzni3AtYlgWorOHQABG5DL6Bl3X0tvLIt1jPs4 z8aOXzX3kzoD9Vvs1gIi6oOdG53/JEpkaEv+qkcyDJLzCz6f9VSJUWK7oOFN96oQowGnxH ohweWLshc1yDDVuAFT/sDAen5GiS2Y0EGhrOQZfArLRNIEeEw7yOgKle79HqxzPKk7bNRc 4V1aLsQzivtG6IJi8F3y0cG+XyjJqO7TwFthbxneDlvUY/+QJHUAg/npCcpYeT2kloatKw ziDnP3mQgOSsAaaoB357hsoojewaAdsvZaEHzh1rncmVOZQU1NTlwRKHQvcRNw== From: Michael Tremer <michael.tremer@ipfire.org> To: development@lists.ipfire.org Subject: [PATCH] QoS: Do not try to unload any kernel modules Date: Tue, 2 Nov 2021 10:53:10 +0000 Message-Id: <20211102105310.22809-1-michael.tremer@ipfire.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Cc: Michael Tremer <michael.tremer@ipfire.org> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
QoS: Do not try to unload any kernel modules
|
|
Commit Message
Michael Tremer
Nov. 2, 2021, 10:53 a.m. UTC
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
---
config/qos/makeqosscripts.pl | 2 --
1 file changed, 2 deletions(-)
Comments
Hello Michael, could you elaborate more on this one? From my basic understanding, QoS should not try to unload kernel modules indeed, but I did not get why it was doing so in the first place. Thanks, and best regards, Peter Müller > Signed-off-by: Michael Tremer <michael.tremer@ipfire.org> > --- > config/qos/makeqosscripts.pl | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/config/qos/makeqosscripts.pl b/config/qos/makeqosscripts.pl > index 0694bb78c..3234ab366 100644 > --- a/config/qos/makeqosscripts.pl > +++ b/config/qos/makeqosscripts.pl > @@ -510,8 +510,6 @@ print <<END > iptables -t mangle --flush QOS-INC >/dev/null 2>&1 > iptables -t mangle --delete-chain QOS-INC >/dev/null 2>&1 > > - rmmod sch_htb >/dev/null 2>&1 > - > for i in \$(ls \$RRDLOG/class_*.rrd); do > rrdtool update \$i \$(date +%s): > done >
Hello, > On 17 Nov 2021, at 20:15, Peter Müller <peter.mueller@ipfire.org> wrote: > > Hello Michael, > > could you elaborate more on this one? Sure. > From my basic understanding, QoS should not try to unload kernel modules indeed, > but I did not get why it was doing so in the first place. Unloading kernel modules used to be an old thing to do. I have no idea really why what the motivation was. Partly to save memory, and partly to not have unused module loaded since hardware for example was being detected by loading every single module and see if it recognised any hardware. Here we unload the HTB scheduler simply because we do not need it any more after the QoS was stopped. However, during an update, it might happen that the QoS needs to be restarted. When the kernel has been updated in the same updater, we no longer have the kernel modules available for the running kernel. Since sch_htb was unloaded, we can no longer load it again. That was the motivation for this patch here. At least QoS continues to work until the system is being rebooted after the update. Does this make sense? -Michael > > Thanks, and best regards, > Peter Müller > > >> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org> >> --- >> config/qos/makeqosscripts.pl | 2 -- >> 1 file changed, 2 deletions(-) >> diff --git a/config/qos/makeqosscripts.pl b/config/qos/makeqosscripts.pl >> index 0694bb78c..3234ab366 100644 >> --- a/config/qos/makeqosscripts.pl >> +++ b/config/qos/makeqosscripts.pl >> @@ -510,8 +510,6 @@ print <<END >> iptables -t mangle --flush QOS-INC >/dev/null 2>&1 >> iptables -t mangle --delete-chain QOS-INC >/dev/null 2>&1 >> - rmmod sch_htb >/dev/null 2>&1 >> - >> for i in \$(ls \$RRDLOG/class_*.rrd); do >> rrdtool update \$i \$(date +%s): >> done
Hello Michael, thanks for your reply. This makes sense to me. Reviewed-by: Peter Müller <peter.mueller@ipfire.org> Thanks, and best regards, Peter Müller > Hello, > >> On 17 Nov 2021, at 20:15, Peter Müller <peter.mueller@ipfire.org> wrote: >> >> Hello Michael, >> >> could you elaborate more on this one? > > Sure. > >> From my basic understanding, QoS should not try to unload kernel modules indeed, >> but I did not get why it was doing so in the first place. > > Unloading kernel modules used to be an old thing to do. I have no idea really why what the motivation was. > > Partly to save memory, and partly to not have unused module loaded since hardware for example was being detected by loading every single module and see if it recognised any hardware. > > Here we unload the HTB scheduler simply because we do not need it any more after the QoS was stopped. However, during an update, it might happen that the QoS needs to be restarted. When the kernel has been updated in the same updater, we no longer have the kernel modules available for the running kernel. Since sch_htb was unloaded, we can no longer load it again. That was the motivation for this patch here. At least QoS continues to work until the system is being rebooted after the update. > > Does this make sense? > > -Michael > >> >> Thanks, and best regards, >> Peter Müller >> >> >>> Signed-off-by: Michael Tremer <michael.tremer@ipfire.org> >>> --- >>> config/qos/makeqosscripts.pl | 2 -- >>> 1 file changed, 2 deletions(-) >>> diff --git a/config/qos/makeqosscripts.pl b/config/qos/makeqosscripts.pl >>> index 0694bb78c..3234ab366 100644 >>> --- a/config/qos/makeqosscripts.pl >>> +++ b/config/qos/makeqosscripts.pl >>> @@ -510,8 +510,6 @@ print <<END >>> iptables -t mangle --flush QOS-INC >/dev/null 2>&1 >>> iptables -t mangle --delete-chain QOS-INC >/dev/null 2>&1 >>> - rmmod sch_htb >/dev/null 2>&1 >>> - >>> for i in \$(ls \$RRDLOG/class_*.rrd); do >>> rrdtool update \$i \$(date +%s): >>> done >
diff --git a/config/qos/makeqosscripts.pl b/config/qos/makeqosscripts.pl index 0694bb78c..3234ab366 100644 --- a/config/qos/makeqosscripts.pl +++ b/config/qos/makeqosscripts.pl @@ -510,8 +510,6 @@ print <<END iptables -t mangle --flush QOS-INC >/dev/null 2>&1 iptables -t mangle --delete-chain QOS-INC >/dev/null 2>&1 - rmmod sch_htb >/dev/null 2>&1 - for i in \$(ls \$RRDLOG/class_*.rrd); do rrdtool update \$i \$(date +%s): done