From: Dominik Brodowski <linux@brodo.de> To: danielk@mrl.nyu.edu Cc: Mattia Dongili <dongili@supereva.it>, linux-kernel@vger.kernel.org, cpufreq@www.linux.org.uk Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver Date: Tue, 21 Oct 2003 22:32:15 +0200 [thread overview] Message-ID: <20031021203215.GE26971@brodo.de> (raw) In-Reply-To: <Pine.SOL.4.53.0310211057060.6187@graphics.cat.nyu.edu> On Tue, Oct 21, 2003 at 11:36:56AM -0400, Daniel Thor Kristjansson wrote: > > The _user_ shouldn't set the cpu frequency hundred of times a second, > but a userland program should set the priorities. If you are just > looking at CPU Temperature and the idle loop for setting your cpu > frequency then it's fine to do it in the kernel. But if you are looking > at dozens of factors and balancing them it is much safer to do so in > userland. Wrong. Passing "events" or "information" to cpufreq governors by cpufreq_governor() is much easier, cheaper, and more reliable. > CPUFreq has been rearchitectured to allow this type of thing, > you can have a governor in the kernel that sets CPU Frequency based on > load within limits specified by a userland program. Wrong again. CPUfreq has been rearchitectured to do this kernel-space. The userspace governor allows setting to specific frequencies by the user ["I _want_ 500 MHz and nothing else!"], and it offers backwards compatibility for the first-era cpufreq interface [LART project etc.]. > ACPI can meantime throttle the CPU if it gets too hot However, frequency scaling is much more efficient on lowering the CPU heat, too. > The user may know things the kernel doesn't such as "this laptop is > burning a hole in my pants." She might want to construct a policy that > doesn't minimize power consumption since she's plugged in, but gives the > CPU lots of juice at first when the idle goes down, but then backs off > if it detects a long running 100% utilization such as during a long > compile. Yes indeed. She wants to set a cpufreq policy which suits of her needs: it consists of a - minimum frequency => not too low [she's plugged in] - maximum frequency => 100% - cpufreq governor => some kind of yet-to-be-written dynamic cpufreq governor with temperature or long-term-statistic knowledge. _I_ wouldn't want to run this governor, though -- I want kernel compiles to complete as fast as possible. So, we need different in-kernel governors. > This would maximize responsiveness in interactive settings but > still keep her lap comfortably cool when compiling mozilla. Putting the > complexity of policies specified by something like an XML file in the > kernel scares me, putting it in a userspace program that communicates > with a low level governor is a more comforting thought. Well, the thing one of the cpufreq userspace programs does is really fine: based on low-frequency events [power plug-in, running specific programs, etc.] different cpufreq policies [see above] are selected. No XML file necessary. Dominik
WARNING: multiple messages have this Message-ID (diff)
From: Dominik Brodowski <linux@brodo.de> To: danielk@mrl.nyu.edu Cc: cpufreq@www.linux.org.uk, linux-kernel@vger.kernel.org, Mattia Dongili <dongili@supereva.it> Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver Date: Tue, 21 Oct 2003 22:32:15 +0200 [thread overview] Message-ID: <20031021203215.GE26971@brodo.de> (raw) In-Reply-To: <Pine.SOL.4.53.0310211057060.6187@graphics.cat.nyu.edu> On Tue, Oct 21, 2003 at 11:36:56AM -0400, Daniel Thor Kristjansson wrote: > > The _user_ shouldn't set the cpu frequency hundred of times a second, > but a userland program should set the priorities. If you are just > looking at CPU Temperature and the idle loop for setting your cpu > frequency then it's fine to do it in the kernel. But if you are looking > at dozens of factors and balancing them it is much safer to do so in > userland. Wrong. Passing "events" or "information" to cpufreq governors by cpufreq_governor() is much easier, cheaper, and more reliable. > CPUFreq has been rearchitectured to allow this type of thing, > you can have a governor in the kernel that sets CPU Frequency based on > load within limits specified by a userland program. Wrong again. CPUfreq has been rearchitectured to do this kernel-space. The userspace governor allows setting to specific frequencies by the user ["I _want_ 500 MHz and nothing else!"], and it offers backwards compatibility for the first-era cpufreq interface [LART project etc.]. > ACPI can meantime throttle the CPU if it gets too hot However, frequency scaling is much more efficient on lowering the CPU heat, too. > The user may know things the kernel doesn't such as "this laptop is > burning a hole in my pants." She might want to construct a policy that > doesn't minimize power consumption since she's plugged in, but gives the > CPU lots of juice at first when the idle goes down, but then backs off > if it detects a long running 100% utilization such as during a long > compile. Yes indeed. She wants to set a cpufreq policy which suits of her needs: it consists of a - minimum frequency => not too low [she's plugged in] - maximum frequency => 100% - cpufreq governor => some kind of yet-to-be-written dynamic cpufreq governor with temperature or long-term-statistic knowledge. _I_ wouldn't want to run this governor, though -- I want kernel compiles to complete as fast as possible. So, we need different in-kernel governors. > This would maximize responsiveness in interactive settings but > still keep her lap comfortably cool when compiling mozilla. Putting the > complexity of policies specified by something like an XML file in the > kernel scares me, putting it in a userspace program that communicates > with a low level governor is a more comforting thought. Well, the thing one of the cpufreq userspace programs does is really fine: based on low-frequency events [power plug-in, running specific programs, etc.] different cpufreq policies [see above] are selected. No XML file necessary. Dominik
next prev parent reply other threads:[~2003-10-21 20:45 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-10-21 2:56 [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-state driver Pallipadi, Venkatesh 2003-10-21 2:56 ` Pallipadi, Venkatesh 2003-10-21 8:38 ` Arjan van de Ven 2003-10-21 8:38 ` Arjan van de Ven 2003-10-21 9:59 ` Mattia Dongili 2003-10-21 9:59 ` Mattia Dongili 2003-10-21 10:17 ` Wichert Akkerman 2003-10-21 10:52 ` Mattia Dongili 2003-10-21 12:59 ` Wichert Akkerman 2003-10-21 15:36 ` Daniel Thor Kristjansson 2003-10-21 20:32 ` Dominik Brodowski [this message] 2003-10-21 20:32 ` Dominik Brodowski 2003-10-22 15:48 ` Daniel Thor Kristjansson 2003-10-22 15:48 ` Daniel Thor Kristjansson 2003-10-23 14:32 ` Pavel Machek 2003-10-23 14:32 ` Pavel Machek 2003-10-24 18:22 ` Dominik Brodowski 2003-10-24 18:22 ` Dominik Brodowski 2003-10-21 19:23 ` Carl Thompson 2003-10-21 20:37 ` Dominik Brodowski 2003-10-21 20:37 ` Dominik Brodowski 2003-10-21 20:44 ` Dominik Brodowski 2003-10-21 20:59 ` Dominik Brodowski 2003-10-23 14:17 ` Pavel Machek 2003-10-23 14:17 ` Pavel Machek 2003-10-23 20:47 ` Moore, Robert 2003-10-23 20:47 ` Moore, Robert 2003-10-23 21:50 ` Nakajima, Jun 2003-10-23 21:50 ` Nakajima, Jun 2003-10-24 18:38 ` Dominik Brodowski 2003-10-24 18:38 ` Dominik Brodowski 2003-10-24 11:27 ` Ducrot Bruno 2003-10-24 11:27 ` Ducrot Bruno 2003-10-22 5:50 Pallipadi, Venkatesh 2003-10-24 18:52 Pallipadi, Venkatesh 2003-10-24 18:52 ` Pallipadi, Venkatesh
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=20031021203215.GE26971@brodo.de \ --to=linux@brodo.de \ --cc=cpufreq@www.linux.org.uk \ --cc=danielk@mrl.nyu.edu \ --cc=dongili@supereva.it \ --cc=linux-kernel@vger.kernel.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.