Re: [systemd-devel] cpufrequtils considered useless
Am Dienstag, den 19.06.2012, 12:10 +0200 schrieb Kay Sievers: On Tue, Jun 19, 2012 at 12:04 PM, Paul Menzel wrote: Am Dienstag, den 19.06.2012, 11:48 +0200 schrieb Lennart Poettering: On Tue, 19.06.12 11:42, Paul Menzel wrote: I guess it is useful to have an abstraction layer because directories and files under `/sys` might change. Nah, really, cpufrequtils should just go away. People should use the kernel APIs right away. alright looking into why `cpufrequtils` is installed on my system I now know the reasons. The frequency(?) modules are not loaded automatically and therefore the init.d script shipped by `cpufrequtils` is needed. This is a not the case anymore for kernels 3.3 and up anymore. CPU feature modules are now loaded automatically based on the CPUID data. great news! So what should distributions having decided to use Linux 3.2 for their next stable release do? Update their kernel. :) Or backport that feature [1][2]. Ben Hutchings rules and I thank him for doing all that great work on the Linux kernel side! Thanks Ben! Or do whatever they used to do in the past and bet it works, like it did most of the time. The problem is pretty much solved from systemd's point of view, so there will be no effort from this side. […] So now Debian Wheezy users on x86 do not need cpufrequtils anymore to load the correct module. Thanks, Paul [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664813 [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678116 signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cpufrequtils considered useless (was: systemd unit files for Debian based systems)
Am Dienstag, den 19.06.2012, 10:03 +0200 schrieb Lennart Poettering: On Mon, 18.06.12 21:56, Paul Menzel (paulepan...@users.sourceforge.net) wrote: Dear Lennart, […] What is cpufrequitls for? Why would anybody fiddle with that? ondemand is the only CPU scheduler that makes sense, so what is this about? Also, you can change the CPU scheduler via simple sysfs writes, right? So why would you use a tool like cpufreq for this? tmpfiles should be entirely sufficient? cpufreq stuff really appears to be sugar for -Oit-feels-so-much-faster-now freaks... In Debian it is a recommendation of the package `gnome-applets`. $ LANG=C aptitude why cpufrequtils i gnome Dependsgnome-applets (= 2.91) i A gnome-applets Recommends cpufrequtils I guess it is useful to have an abstraction layer because directories and files under `/sys` might change. Nah, really, cpufrequtils should just go away. People should use the kernel APIs right away. alright looking into why `cpufrequtils` is installed on my system I now know the reasons. The frequency(?) modules are not loaded automatically and therefore the init.d script shipped by `cpufrequtils` is needed. $ zless /usr/share/doc/gnome-applets/changelog.Debian.gz […] gnome-applets (2.24.2-1) experimental; urgency=low * es.po: updated Spanish translation from Francisco Javier Cuadrado. Closes: #502236. * Recommend cpufrequtils. Closes: #448833. The mentioned Debian bug reports #448833 [8] and #509827 [9] contain the discussion. Without the appropriate modules loaded – in my case `powernow_k8` – no power saving features of the CPU are available. $ find /sys -iname '*cpufreq*' /sys/devices/system/cpu/cpufreq $ ls -l /sys/devices/system/cpu/cpufreq/ insgesamt 0 $ sudo modprobe powernow_k8 $ ls -l /sys/devices/system/cpu/cpufreq/ insgesamt 0 drwxr-xr-x 2 root root 0 Jun 19 11:18 ondemand So how is this supposed to work out of the box? Thanks, Paul [8] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448833 [9] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509827 signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cpufrequtils considered useless (was: systemd unit files for Debian based systems)
On Tue, 19.06.12 11:42, Paul Menzel (paulepan...@users.sourceforge.net) wrote: Heya, I guess it is useful to have an abstraction layer because directories and files under `/sys` might change. Nah, really, cpufrequtils should just go away. People should use the kernel APIs right away. alright looking into why `cpufrequtils` is installed on my system I now know the reasons. The frequency(?) modules are not loaded automatically and therefore the init.d script shipped by `cpufrequtils` is needed. This is a not the case anymore for kernels 3.3 and up anymore. CPU feature modules are now loaded automatically based on the CPUID data. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cpufrequtils considered useless
Am Dienstag, den 19.06.2012, 11:48 +0200 schrieb Lennart Poettering: On Tue, 19.06.12 11:42, Paul Menzel (paulepan...@users.sourceforge.net) wrote: Dear Lennart, I guess it is useful to have an abstraction layer because directories and files under `/sys` might change. Nah, really, cpufrequtils should just go away. People should use the kernel APIs right away. alright looking into why `cpufrequtils` is installed on my system I now know the reasons. The frequency(?) modules are not loaded automatically and therefore the init.d script shipped by `cpufrequtils` is needed. This is a not the case anymore for kernels 3.3 and up anymore. CPU feature modules are now loaded automatically based on the CPUID data. great news! So what should distributions having decided to use Linux 3.2 for their next stable release do? Thanks, Paul signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cpufrequtils considered useless (was: systemd unit files for Debian based systems)
On Tue, Jun 19, 2012 at 11:42:10AM +0200, Paul Menzel wrote: Nah, really, cpufrequtils should just go away. People should use the kernel APIs right away. alright looking into why `cpufrequtils` is installed on my system I now know the reasons. The frequency(?) modules are not loaded automatically and therefore the init.d script shipped by `cpufrequtils` is needed. Without the appropriate modules loaded – in my case `powernow_k8` – no power saving features of the CPU are available. So how is this supposed to work out of the box? This was fixed in kernel (1.4. x86 CPU driver autoprobing): http://kernelnewbies.org/Linux_3.4#head-9df4e508cb97f4e138c590b9ccff3e0eda6cc7fc -- Tomasz Torcz God, root, what's the difference? xmpp: zdzich...@chrome.pl God is more forgiving. pgpIsdgNJrpyX.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cpufrequtils considered useless
On Tue, Jun 19, 2012 at 12:04 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Am Dienstag, den 19.06.2012, 11:48 +0200 schrieb Lennart Poettering: On Tue, 19.06.12 11:42, Paul Menzel (paulepan...@users.sourceforge.net) wrote: I guess it is useful to have an abstraction layer because directories and files under `/sys` might change. Nah, really, cpufrequtils should just go away. People should use the kernel APIs right away. alright looking into why `cpufrequtils` is installed on my system I now know the reasons. The frequency(?) modules are not loaded automatically and therefore the init.d script shipped by `cpufrequtils` is needed. This is a not the case anymore for kernels 3.3 and up anymore. CPU feature modules are now loaded automatically based on the CPUID data. great news! So what should distributions having decided to use Linux 3.2 for their next stable release do? Update their kernel. :) Or do whatever they used to do in the past and bet it works, like it did most of the time. The problem is pretty much solved from systemd's point of view, so there will be no effort from this side. The only safe option was to compile all of the cpufreq modules into the kernel. The drivers implement fallback and legacy support, so the driver loading order is important. Userspace would need to know in which order to try them out, which is seriously nothing userspace should ever pretend to know. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cpufrequtils considered useless
'Twas brillig, and Kay Sievers at 19/06/12 11:10 did gyre and gimble: On Tue, Jun 19, 2012 at 12:04 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Am Dienstag, den 19.06.2012, 11:48 +0200 schrieb Lennart Poettering: On Tue, 19.06.12 11:42, Paul Menzel (paulepan...@users.sourceforge.net) wrote: I guess it is useful to have an abstraction layer because directories and files under `/sys` might change. Nah, really, cpufrequtils should just go away. People should use the kernel APIs right away. alright looking into why `cpufrequtils` is installed on my system I now know the reasons. The frequency(?) modules are not loaded automatically and therefore the init.d script shipped by `cpufrequtils` is needed. This is a not the case anymore for kernels 3.3 and up anymore. CPU feature modules are now loaded automatically based on the CPUID data. great news! So what should distributions having decided to use Linux 3.2 for their next stable release do? Update their kernel. :) Or do whatever they used to do in the past and bet it works, like it did most of the time. The problem is pretty much solved from systemd's point of view, so there will be no effort from this side. The only safe option was to compile all of the cpufreq modules into the kernel. The drivers implement fallback and legacy support, so the driver loading order is important. Userspace would need to know in which order to try them out, which is seriously nothing userspace should ever pretend to know. The other option would be to have a small service that runs once, detects the relevant hardware and then setups up an appropriate modprobe.preload.d file (or similar) for use on subsequent boots. Detect once, then use static configs there after. Roll on 3.3. Nice to hear it's all automatic now :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cpufrequtils considered useless
On Tue, 19.06.12 19:06, Colin Guthrie (gm...@colin.guthr.ie) wrote: Or do whatever they used to do in the past and bet it works, like it did most of the time. The problem is pretty much solved from systemd's point of view, so there will be no effort from this side. The only safe option was to compile all of the cpufreq modules into the kernel. The drivers implement fallback and legacy support, so the driver loading order is important. Userspace would need to know in which order to try them out, which is seriously nothing userspace should ever pretend to know. The other option would be to have a small service that runs once, detects the relevant hardware and then setups up an appropriate modprobe.preload.d file (or similar) for use on subsequent boots. Detect once, then use static configs there after. Well, but we actually try hard to make our systems as stateless as possible and not require / to be writable. i.e. we want to be able to boot the same image on real hardware of any kind, in a VM of any kind or in a container of any kind. But with making static changes to the OS like this you effectively break that logic... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cpufrequtils considered useless
'Twas brillig, and Lennart Poettering at 19/06/12 19:58 did gyre and gimble: On Tue, 19.06.12 19:06, Colin Guthrie (gm...@colin.guthr.ie) wrote: Or do whatever they used to do in the past and bet it works, like it did most of the time. The problem is pretty much solved from systemd's point of view, so there will be no effort from this side. The only safe option was to compile all of the cpufreq modules into the kernel. The drivers implement fallback and legacy support, so the driver loading order is important. Userspace would need to know in which order to try them out, which is seriously nothing userspace should ever pretend to know. The other option would be to have a small service that runs once, detects the relevant hardware and then setups up an appropriate modprobe.preload.d file (or similar) for use on subsequent boots. Detect once, then use static configs there after. Well, but we actually try hard to make our systems as stateless as possible and not require / to be writable. i.e. we want to be able to boot the same image on real hardware of any kind, in a VM of any kind or in a container of any kind. But with making static changes to the OS like this you effectively break that logic... Yeah but my comments were in the context of the options when running under a 3.2 kernel. I'm obviously very much more in favour of the 3.3 approach with it's autoloading-fu which would negate the need for such detection tools (and whether said tools write a static config or just do the module loading themselves is really just down to boot speed really - either approach has trade-offs) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
