On Wed, Apr 7, 2010 at 10:00 PM, Ben Gamari <bgamari.f...@gmail.com> wrote: > On Wed, 7 Apr 2010 13:25:30 -0500, Mike Turquette <mturque...@gmail.com> > wrote: >> Hi all, >> >> I was glancing over the QoS aspects of upower, and the control knobs >> all appear to be related to latency. >> >> What if I had a codec for, say, video playback and I know it needs X >> MHz to run properly. How could upower help me to do this? I'll >> assume I have some cpufreq governor running in the background, but I >> don't want to rely on that to get the job done when I already know my >> frequency requirements. >> >> I guess my real question is, will frequency-based QoS knobs ever make >> their way into upower? I know the hot topics these days are >> constraints (dma latency, cpu wake up latency, network throughput, >> etc), but sometimes you just need the megahertz. >> > You seem to be assuming that the cpufreq governor somehow does an inferior > job of keeping up with your computational requirements. If the ondemand > governor (which should be used in pretty much all cases) isn't giving you > the clockrate necessary to keep up with your workload, then that's a bug.
/me rolls up sleeves I agree with the above. Believe me that I understand *precisely* why requesting MHz directly is wrong. I was hoping to keep this discussion conceptually generic, but I think I should explain my concern further. I am currently working on an OMAP board, which is an ARM-based SoC with a DSP bolted on plus a bunch of other stuff. For the purposes of managing power and performance there are tuples commonly called operating points that consist of ARM frequency, DSP frequency and voltage across a common bus. My codec runs on the DSP, and I'm exploring different methods to make sure that the operating point selected by logic on the ARM (cpufreq, pm constraints, whatever) does justice by the DSP's needs as well. From the userspace perspective, I *know* how many MHz on the DSP I need for my codec to run. Since DSP speed is tied to ARM speed through the operating points I was hoping to use upower to place a minimum frequency requirement. cpufreq governors like ondemand will not do this since it knows nothing of the DSP's needs. There are lots of ways to solve this: - write a cpufreq governor that takes the DSPs load into account (assuming that the load information is exported by the DSP software) - use userspace governor to select an ARM frequency that maps to the needs of DSP (horrible idea) - use a nice piece of plumbing to place a frequency constraint on the CPU To give even more detail, the kernel driver that handles communication with the DSP is not intelligent. It does not know that the codec just loaded is for MPEG4 video and needs X MHz. So this constraint cannot easily be made in the kernel. The userspace daemon responsible for loading the codec binary blobs knows this info, so the best place to understand the MHz requirements for different codecs (mp3 vs aac vs h.264) comes from userspace. I understand if everyone vomits at the thought of such wicked and despicable embedded stuff, but I would really like to discuss how to handle such cases. With the increasing number of coprocessors in all manner of computers these days, this is a problem that others will face. Mike > Cpufreq is the correct solution here. While you might think you know your > frequency requirements today, they will invariably change over time and > between > machines. UPower doesn't implement frequency-based QoS management because it's > fundamentally the wrong approach. This is what cpufreq is for. > > You might want to take a look at Matthew Garrett's excellent blog[1] on CPU > power > management. I think it will help dispel a bunch of misconceptions you have > formed. > > - Ben > > [1] http://mjg59.livejournal.com/88608.html > _______________________________________________ devkit-devel mailing list devkit-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/devkit-devel
