Messages in this thread | | | Subject | RE: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPIP-state driver | Date | Tue, 21 Oct 2003 10:41:30 -0700 | From | "Pallipadi, Venkatesh" <> |
| |
We can have a userspace governor and take decisions using top, /proc/interrupts etc. But issue is mostly the rate at which we want to monitor. In kernel governor can afford to do more frequent checks and use the low latency P-state change feature quite effectively.
The patch does take care of all kinds of loads, process or irq as we look at the cpu idle time in kstat. However it waits until scheduled work (schedule_work()) gets to run. As you say, another advantage of having this in kernel is, kernel has all the information to take such decisions quickly. At present, The patch tries to keep this governor simple and cover the common cases. However, once we have the infrastructure in place, further optimizations with more advanced things can be done based on actual performance data.
Thanks, -Venkatesh
> -----Original Message----- > From: Arjan van de Ven [mailto:arjanv@redhat.com] > Sent: Tuesday, October 21, 2003 1:39 AM > To: Pallipadi, Venkatesh > Cc: cpufreq@www.linux.org.uk; linux-kernel@vger.kernel.org; > linux-acpi; Mallick, Asit K; Nakajima, Jun; Dominik Brodowski > Subject: Re: [PATCH] 3/3 Dynamic cpufreq governor and updates > to ACPIP-state driver > > > On Tue, 2003-10-21 at 04:56, Pallipadi, Venkatesh wrote: > > Patch 3/3: New dynamic cpufreq driver (called > > DemandBasedSwitch driver), which periodically monitors CPU > > usage and changes the CPU frequency based on the demand. > > > it's all nice code and such, but I still wonder why this can't be done > by a userland policy daemon. The 2.6 kernel has the infrastructure to > give very detailed information to userspace (eg top etc) about idle > percentages...... I didn't see anything in this driver that > couldn't be > done from userspace. > > Note that I'm not totally against doing some of this in the kernel; I > can well see the point of say, detecting an IRQ overload and based on > that, go to max speed in the kernel because it's a situation where > userspace doesn't even run; but the patch as is doesn't do any such > advanced things... > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |