Re: [PATCH] 3/3 Dynamic cpufreq governor and updates to ACPI P-statedriver

[Daniel Thor Kristjansson]

]> 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
]Wrong. Passing "events" or "information" to cpufreq governors by
]cpufreq_governor() is much easier, cheaper, and more reliable.

I think we may actually agree, but I may be wrong.

I have no problem with a governor setting the frequency and voltage
based on idle or temperature measurements only it can see efficiently.
But I think you still want more complex things to be decided in userland
which is more forgiving to programmer error. For instance this patch
does not allow you to tailor the polling frequency, if someone wrote a
such a governor that took battery into account my Vaio FXA53 would come
to a grinding halt as checking the battery through ACPI stops the
machine cold for about 200 ms. There is no need to poll the battery very
often, but someone with a fast battery check might do so simply out of
convenience.

]> 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.].
No, you can set a min and max frequency that the governor is allowed to
move within. This can be done by a userspace program through the /sys
interface. You can also use the "userspace" governor, but that's not
what I'm recommending.

]> ACPI can meantime throttle the CPU if it gets too hot
]However, frequency scaling is much more efficient on lowering the CPU heat,
]too.
Sure, a governor that does goes to the minimum frequency it's userland
governor has told it it has available to cool the CPU is a good thing.
Or, even below that if the CPU is near critical. If the CPU gets that
hot there is something wrong with the userland policy. Until this is
written, ACPI can act as a backup system to keep the CPU from burning
up.

]> 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
]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.
Why not a sensible governor in the kernel and a userland governor that
sets the minimum and maximum for desired effect?

]_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.
I think a governor could keep the CPU running at 100% for long enough to
finish a kernel compile while still slowing down for a really long
compile like KDE, Mozilla, etc. It might however be too complex for me
to feel comfortable with it in the kernel.

]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.

Yes, the userspace program can just switch from performance, to
something in between w/min/max, to powersave. My arguement is just
against making the "something in between" too complex, by for
instance taking the low-frequency events into account.

-- Daniel
  <<McCain was held in a bamboo cage and poked at with sticks for years.
    That's the kind of guy who should be in the White House.>> -- Anon.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/