From: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
To: "Meyer, Kyle" <kyle.meyer@hpe.com>, LKML <linux-kernel@vger.kernel.org>
Cc: "rjw@rjwysocki.net" <rjw@rjwysocki.net>,
"viresh.kumar@linaro.org" <viresh.kumar@linaro.org>,
"lenb@kernel.org" <lenb@kernel.org>
Subject: Re: [RFC] cpufreq: Excessive CPUFreq driver loading
Date: Fri, 14 May 2021 09:15:14 -0700 [thread overview]
Message-ID: <76e9c2ae095184930669856e9f1a886d92b83f36.camel@linux.intel.com> (raw)
In-Reply-To: <TU4PR8401MB05927B583A481A3F1823CD549B509@TU4PR8401MB0592.NAMPRD84.PROD.OUTLOOK.COM>
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@hpe.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
prev parent reply other threads:[~2021-05-14 16:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-06 14:25 [RFC] cpufreq: Excessive CPUFreq driver loading Meyer, Kyle
2021-05-14 14:06 ` Meyer, Kyle
2021-05-14 16:15 ` Srinivas Pandruvada [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=76e9c2ae095184930669856e9f1a886d92b83f36.camel@linux.intel.com \
--to=srinivas.pandruvada@linux.intel.com \
--cc=kyle.meyer@hpe.com \
--cc=lenb@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).