linux-kernel - Re: [RFC] cpufreq: Excessive CPUFreq driver loading

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <76e9c2ae095184930669856e9f1a886d92b83f36.camel@linux.intel.com>
Date:   Fri, 14 May 2021 09:15:14 -0700
From:   Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
To:     "Meyer, Kyle" <kyle.meyer@....com>,
        LKML <linux-kernel@...r.kernel.org>
Cc:     "rjw@...ysocki.net" <rjw@...ysocki.net>,
        "viresh.kumar@...aro.org" <viresh.kumar@...aro.org>,
        "lenb@...nel.org" <lenb@...nel.org>
Subject: Re: [RFC] cpufreq: Excessive CPUFreq driver loading

On Fri, 2021-05-14 at 14:06 +0000, Meyer, Kyle wrote:
> Adding maintainers to the CC list.
> 
> Thank you,
> Kyle Meyer
> 
> ________________________________________
> From: Meyer, Kyle <kyle.meyer@....com>
> Sent: Thursday, May 6, 2021 9:25 AM
> To: LKML
> Subject: [RFC] cpufreq: Excessive CPUFreq driver loading
> 
> Hello,
> 
> acpi-cpufreq is mutually exclusive with intel_pstate, however, acpi-
> cpufreq is
> loaded multiple times during startup while intel_pstate is enabled.
> 
> This issue was reported to the systemd maintainers and they indicated
> that it
> should be fixed in the kernel: 
> https://github.com/systemd/systemd/issues/19439
> 
> During startup, the kernel triggers one uevent for each device as a
> result of
> systemd-udev-trigger.service executing "udevadm trigger --
> type=subsystems
> --action=add" and "udevadm trigger --type=devices --action=add". The
> service
> exists to retrigger all devices as uevents sent by the kernel, before
> systemd-udevd is running, would have been missed. When systemd-udevd
> receives a
> uevent it matches its configured rules against the device. If a
> uevent's
> ACTION=="add", systemd-udevd will run "kmod load $env{MODALIAS}" from
> 80-drivers.rules. udev's builtin kmod will then attempt to load
> modules
> matching the device's MODALIAS.
> 
> When systemd-udevd recieves an "add" uevent from
> /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:XXX it runs "kmod load
> cpu:type:x86,
> ...,00E8,..." as "cpu:type:x86,...,00E8,..." is that devices
> MODALIAS.
> 
> When systemd-udevd recieves an "add" uevent from
> /devices/system/cpu/cpuXXX it
> runs "kmod load acpi:ACPI0007:" as "acpi:ACPI0007:" is that devices
> MODALIAS.
> 
> acpi-cpufreq is loaded as it matches both devices MODALIASes.
> # modinfo acpi-cpufreq | grep alias
> alias:          acpi
> alias:          cpu:type:x86,ven*fam*mod*:feature:*00E8*
> alias:          cpu:type:x86,ven*fam*mod*:feature:*0016*
> alias:          acpi*:ACPI0007:*
> alias:          acpi*:LNXCPU:*
> 
> On a system with 1536 logical CPUs, systemd-udevd attempts to load
> acpi-cpufreq
> 3072 times.
> 
> 1536 * /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0007:XXX
> 1536 * /devices/system/cpu/cpuXXX
> 
> The delay, caused by systemd-udevd attempting to load the driver, has
> a
> significant impact on the startup time. It causes some devices to be
> unavailable after reaching the root login prompt as it postpones the
> loading of
> other drivers.
> 
> Each time that the driver is loaded it returns -EEXIST from
> acpi_cpufreq_init.
> static int __init acpi_cpufreq_init(void)
> {
>         int ret;
> 
>         if (acpi_disabled)
>                 return -ENODEV;
> 
>         /* don't keep reloading if cpufreq_driver exists */
>         if (cpufreq_get_current_driver())
>                 return -EEXIST;
> ...
> 
> Changing the return value from -EEXIST to 0 when another driver
> exists prevents
> the driver from being loaded multiple times as kmod won't load a
> "live" module.
> Alternatively, blacklisting the driver (or disabling intel_pstate)
> prevents the
> issue as well. Below are the before and after startup times.
> 
> # systemd-analyze
> Startup finished in 37.939s (kernel) + 10.909s (initrd) + 3min
> 55.004s (userspace) = 4min 43.852s
> 
> # systemd-analyze
> Startup finished in 38.307s (kernel) + 10.205s (initrd) + 38.312s
> (userspace) = 1min 26.826s

That is a big difference. i think when you return 0, lsmod will show
the module loaded. But that shouldn't be a problem in my opinion.

Thanks,
Srinivas




> 
> Thank you,
> Kyle Meyer