Remove p4_clockmode driver

Remove p4_clockmode driver

The driver is doing throttling which is supposed to be done through another ACPI interface. If both interfaces are used, the machine may get very slow. Remove this driver which should never be used.

Signed-off-by Thomas Renninger <[email protected]>

So whilst killing this off is probably the right thing to do, there may be some value in parts of it living on in the ACPI code ?

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Dave Jones
Sent: Sunday, May 11, 2008 9:20 AM
To: Thomas Renninger
Cc: cpufreq; [email protected]; Dominik Brodowski
Subject: Re: [PATCH] Remove p4_clockmode driver

Quoted 3 lines · Thomas Renninger

Remove p4_clockmode driver

The driver is doing throttling which is supposed to be done

through another

Quoted 1 line

ACPI interface. If both interfaces are used, the machine

may get very slow.

Quoted 3 lines

Remove this driver which should never be used.

Signed-off-by Thomas Renninger <[email protected]>

I agree this is long overdue being taken out back and shot.

Some thoughts though:

* Should we deprecate this for a release first ?
I'm torn over this, because I think no matter how long we do
this for,
we're going to get people who claim to be surprised. Though given this driver is 99% useless, perhaps just ripping it out is for the best.

* Matthew Garrett mentioned something interesting this morning..

mjg59 | davej: On machines that don't support acpi throttling, I was under the impression that there was supposed to be a hook between the thermal code and cpufreq
mjg59 | Which would then let p4-clockmod be kicked even if it's below the threshold at which the CPU would throttle itself davej | having that code expose T states rather than pretend to be P states is probably for the best.
mjg59 | Yeah, true

So whilst killing this off is probably the right thing to
do, there may be
some value in parts of it living on in the ACPI code ?

Quoted 7 lines · Thomas Renninger

Remove p4_clockmode driver

The driver is doing throttling which is supposed to be done through another ACPI interface. If both interfaces are used, the machine may get very slow. Remove this driver which should never be used.

Signed-off-by Thomas Renninger <[email protected]>

I agree this is long overdue being taken out back and shot.

Some thoughts though:

* Should we deprecate this for a release first ?
I'm torn over this, because I think no matter how long we do this for, we're going to get people who claim to be surprised. Though given this driver is 99% useless, perhaps just ripping it out is for the best.

* Matthew Garrett mentioned something interesting this morning..

mjg59 | davej: On machines that don't support acpi throttling, I was under the impression that there was supposed to be a hook between the thermal code and cpufreq
mjg59 | Which would then let p4-clockmod be kicked even if it's below the threshold at which the CPU would throttle itself
davej | having that code expose T states rather than pretend to be P states is probably for the best.
mjg59 | Yeah, true

So whilst killing this off is probably the right thing to do, there may be some value in parts of it living on in the ACPI code ?

I'll queue up this removal patch for linux-next, and we'll see if anyone screams. (I doubt it, given the amount of testing that gets right now. It'll probably not really get noticed until after it's in a Linus sanctioned release)

Hi Dave,

Quoted 26 lines · Dave Jones

Quoted 7 lines · Thomas Renninger

Remove p4_clockmode driver

The driver is doing throttling which is supposed to be done through another ACPI interface. If both interfaces are used, the machine may get very slow. Remove this driver which should never be used.

Signed-off-by Thomas Renninger <[email protected]>

I agree this is long overdue being taken out back and shot.

Some thoughts though:

* Should we deprecate this for a release first ?
I'm torn over this, because I think no matter how long we do this for, we're going to get people who claim to be surprised. Though given this driver is 99% useless, perhaps just ripping it out is for the best.

* Matthew Garrett mentioned something interesting this morning..

mjg59 | davej: On machines that don't support acpi throttling, I was under the impression that there was supposed to be a hook between the thermal code and cpufreq
mjg59 | Which would then let p4-clockmod be kicked even if it's below the threshold at which the CPU would throttle itself
davej | having that code expose T states rather than pretend to be P states is probably for the best.
mjg59 | Yeah, true

Quoted 7 lines

So whilst killing this off is probably the right thing to do, there may be some value in parts of it living on in the ACPI code ?

I'll queue up this removal patch for linux-next, and we'll see if anyone screams. (I doubt it, given the amount of testing that gets right now. It'll probably not really get noticed until after it's in a Linus sanctioned release)

AAAAAAA!</scream>

I am using p4_clockmod in attempt to keep my old P4-based box a bit cooler. It does not support anything besides C0 (no P-states, no throttling) so acpi-based driver does not work.

Quoted 37 lines · Dmitry Torokhov

Hi Dave,

Quoted 33 lines · Dave Jones

Quoted 7 lines · Thomas Renninger

Remove p4_clockmode driver

The driver is doing throttling which is supposed to be done through another ACPI interface. If both interfaces are used, the machine may get very slow. Remove this driver which should never be used.

Signed-off-by Thomas Renninger <[email protected]>

I agree this is long overdue being taken out back and shot.

Some thoughts though:

* Should we deprecate this for a release first ?
I'm torn over this, because I think no matter how long we do this for, we're going to get people who claim to be surprised. Though given this driver is 99% useless, perhaps just ripping it out is for the best.

* Matthew Garrett mentioned something interesting this morning..

mjg59 | davej: On machines that don't support acpi throttling, I was under the impression that there was supposed to be a hook between the thermal code and cpufreq
mjg59 | Which would then let p4-clockmod be kicked even if it's below the threshold at which the CPU would throttle itself
davej | having that code expose T states rather than pretend to be P states is probably for the best.
mjg59 | Yeah, true

So whilst killing this off is probably the right thing to do, there may be some value in parts of it living on in the ACPI code ?

I'll queue up this removal patch for linux-next, and we'll see if anyone screams. (I doubt it, given the amount of testing that gets right now. It'll probably not really get noticed until after it's in a Linus sanctioned release)

Quoted 5 lines

AAAAAAA!</scream>

I am using p4_clockmod in attempt to keep my old P4-based box a bit cooler. It does not support anything besides C0 (no P-states, no throttling) so acpi-based driver does not work.

P4 CPUs do waste power, it is not designed for power savings. How much do you save with p4-clockmod?

But maybe a reimplementation as Matthew suggested it may really be worth it. If it is, someone probably will do it.

The cpufreq interface is the wrong place for this driver. If you have a machine that exposes throttling as expected and you make use of it (and there are userspace tools doing this), you are busted.

Instead of screaming, better provide suggestions for a proper integration for machines which are capable of throttling, but have a broken BIOS which does not export it (maybe they are just doing this because it's not worth it?).

AFAIK there are AMD drivers with static cpufreq tables which were never accepted. People with a BIOS who's CPU is not detected and cpufreq info is not exposed have bad luck and must either poke the vendor or self-compile the out-of-tree static table solution.
I would 10 times more support this to be integrated because:
- It fits the design and does not slow down other machines as a side effect
- It really saves some power
I still think it's ok that it did not go mainline, for maintenance and "it's the wrong way" reasons.

Please, if you have verified that it really saves power (I'd really like to see some figures here, I never saw any for p4-clockmod) and it's worth having it, help to get this implemented properly, but do not delay a process which is overdue for a long time already.

Hi Thomas,

Quoted 44 lines · Thomas Renninger

Quoted 42 lines · Dmitry Torokhov

Hi Dave,

Quoted 26 lines · Dave Jones

Quoted 7 lines · Thomas Renninger

Remove p4_clockmode driver

The driver is doing throttling which is supposed to be done through another ACPI interface. If both interfaces are used, the machine may get very slow. Remove this driver which should never be used.

Signed-off-by Thomas Renninger <[email protected]>

I agree this is long overdue being taken out back and shot.

Some thoughts though:

* Should we deprecate this for a release first ?
I'm torn over this, because I think no matter how long we do this for, we're going to get people who claim to be surprised. Though given this driver is 99% useless, perhaps just ripping it out is for the best.

* Matthew Garrett mentioned something interesting this morning..

mjg59 | davej: On machines that don't support acpi throttling, I was under the impression that there was supposed to be a hook between the thermal code and cpufreq
mjg59 | Which would then let p4-clockmod be kicked even if it's below the threshold at which the CPU would throttle itself
davej | having that code expose T states rather than pretend to be P states is probably for the best.
mjg59 | Yeah, true

Quoted 7 lines

So whilst killing this off is probably the right thing to do, there may be some value in parts of it living on in the ACPI code ?

I'll queue up this removal patch for linux-next, and we'll see if anyone screams. (I doubt it, given the amount of testing that gets right now. It'll probably not really get noticed until after it's in a Linus sanctioned release)

AAAAAAA!</scream>

I am using p4_clockmod in attempt to keep my old P4-based box a bit cooler. It does not support anything besides C0 (no P-states, no throttling) so acpi-based driver does not work.

Quoted 3 lines

P4 CPUs do waste power, it is not designed for power savings. How much do you save with p4-clockmod?

Zilch. As I said I am not really try to save power but I am trying to keep my room a bit cooler when I leave the box idle.

Quoted 7 lines

But maybe a reimplementation as Matthew suggested it may really be worth it. If it is, someone probably will do it.

The cpufreq interface is the wrong place for this driver. If you have a machine that exposes throttling as expected and you make use of it (and there are userspace tools doing this), you are busted.

And I don't care since:

a) my box does not expose it and
b) I might or might not be using such tools, depending on my circumstances

Quoted 5 lines

Instead of screaming, better provide suggestions for a proper integration for machines which are capable of throttling, but have a broken BIOS which does not export it (maybe they are just doing this because it's not worth it?).

Quoted 11 lines

AFAIK there are AMD drivers with static cpufreq tables which were never accepted. People with a BIOS who's CPU is not detected and cpufreq info is not exposed have bad luck and must either poke the vendor or self-compile the out-of-tree static table solution.
I would 10 times more support this to be integrated because:
- It fits the design and does not slow down other machines as a side effect
- It really saves some power
I still think it's ok that it did not go mainline, for maintenance and "it's the wrong way" reasons.

The difference here is that p4_clockmod is _in_ mainline so by simply removing it you introduce regression.

You can't just remove driver
without providing a similarly working replacement. If you are concerned about unwanted iteractions with ACPI code you could either add a hook disabling p4_clockmod when acpi throtting gets loaded, or put a big bfat warning about p4_clockmod in dmesg and make it depend on CONFIG_EXPERIMENTAL or CONFIG_EMBEDDED.

Quoted 5 lines

Please, if you have verified that it really saves power (I'd really like to see some figures here, I never saw any for p4-clockmod) and it's worth having it, help to get this implemented properly, but do not delay a process which is overdue for a long time already.

The process woudld be to implement the new way properly and then retire the old driver. You are putting a carriage before the horse here.

Quoted 51 lines · Dmitry Torokhov

Hi Thomas,

Quoted 47 lines · Thomas Renninger

Quoted 37 lines · Dmitry Torokhov

Hi Dave,

Quoted 26 lines · Dave Jones

Quoted 7 lines · Thomas Renninger

Remove p4_clockmode driver

The driver is doing throttling which is supposed to be done through another ACPI interface. If both interfaces are used, the machine may get very slow. Remove this driver which should never be used.

Signed-off-by Thomas Renninger <[email protected]>

I agree this is long overdue being taken out back and shot.

Some thoughts though:

* Should we deprecate this for a release first ?
I'm torn over this, because I think no matter how long we do this for, we're going to get people who claim to be surprised. Though given this driver is 99% useless, perhaps just ripping it out is for the best.

* Matthew Garrett mentioned something interesting this morning..

mjg59 | davej: On machines that don't support acpi throttling, I was under the impression that there was supposed to be a hook between the thermal code and cpufreq
mjg59 | Which would then let p4-clockmod be kicked even if it's below the threshold at which the CPU would throttle itself
davej | having that code expose T states rather than pretend to be P states is probably for the best.
mjg59 | Yeah, true

Quoted 7 lines

So whilst killing this off is probably the right thing to do, there may be some value in parts of it living on in the ACPI code ?

I'll queue up this removal patch for linux-next, and we'll see if anyone screams. (I doubt it, given the amount of testing that gets right now. It'll probably not really get noticed until after it's in a Linus sanctioned release)

Quoted 5 lines

AAAAAAA!</scream>

I am using p4_clockmod in attempt to keep my old P4-based box a bit cooler. It does not support anything besides C0 (no P-states, no throttling) so acpi-based driver does not work.

P4 CPUs do waste power, it is not designed for power savings. How much do you save with p4-clockmod?

Quoted 2 lines

Zilch. As I said I am not really try to save power but I am trying to keep my room a bit cooler when I leave the box idle.

Having people believe they get a cooler room without saving power is a nice feature. Removing it is not a regression. This is exactly what the p4_clockmod driver suggests and what people were complaining "Windows is running with 300 MHz on my P4", it's nice marketing, but not reality. Intel told me they did some tests with SMP machines where throttling actually increases the power consumption.

Quoted 33 lines

Quoted 8 lines

But maybe a reimplementation as Matthew suggested it may really be worth it. If it is, someone probably will do it.

The cpufreq interface is the wrong place for this driver. If you have a machine that exposes throttling as expected and you make use of it (and there are userspace tools doing this), you are busted.

And I don't care since:

a) my box does not expose it and
b) I might or might not be using such tools, depending on my circumstances

Quoted 16 lines

Instead of screaming, better provide suggestions for a proper integration for machines which are capable of throttling, but have a broken BIOS which does not export it (maybe they are just doing this because it's not worth it?).

AFAIK there are AMD drivers with static cpufreq tables which were never accepted. People with a BIOS who's CPU is not detected and cpufreq info is not exposed have bad luck and must either poke the vendor or self-compile the out-of-tree static table solution.
I would 10 times more support this to be integrated because:
- It fits the design and does not slow down other machines as a side effect
- It really saves some power
I still think it's ok that it did not go mainline, for maintenance and "it's the wrong way" reasons.

Quoted 2 lines

The difference here is that p4_clockmod is _in_ mainline so by simply removing it you introduce regression.

Please prove, I do not see a regression.

How much Watts does the machine
save power when it is idle using p4-clockmod?

Quoted 8 lines

You can't just remove driver
without providing a similarly working replacement. If you are concerned about unwanted iteractions with ACPI code you could either add a hook disabling p4_clockmod when acpi throtting gets loaded, or put a big bfat warning about p4_clockmod in dmesg and make it depend on CONFIG_EXPERIMENTAL or CONFIG_EMBEDDED.

Quoted 7 lines

Quoted 5 lines

Please, if you have verified that it really saves power (I'd really like to see some figures here, I never saw any for p4-clockmod) and it's worth having it, help to get this implemented properly, but do not delay a process which is overdue for a long time already.

The process woudld be to implement the new way properly and then retire the old driver. You are putting a carriage before the horse here.

This will never happen. Nobody cares about throttling because it doesn't save you anything. So we have broken machines (through double throttling) and a driver which is of no (at least not much) use.

This reminds me about the broken drivers/acpi/video.c state:
http://bugzilla.kernel.org/show_bug.cgi?id=9614
ThinkPads do use the wrong ACPI device (Nvidia instead Intel ACPI graphics device) and therefore works by luck.
The correct fix, making a lot other models work is ignored because for the Intel ACPI graphics device there is no ACPI (IGD) Linux driver. There even is a workaround to get the ThinkPad working by using thinkpad_acpi driver for brightness switching...
Now everything is broken and will stay like that, because the change will introduce a regression for ThinkPads (cannot switch brightness via video.c for Intel ACPI graphics device, poking with the wrong HW device works somehow...).
What I mean..., the regression argument is a powerful one, misusing it for unimportant, wrong designed or broken implementations (at least the first two are valid here) can make things worse.

Quoted 2 lines

How much Watts does the machine
save power when it is idle using p4-clockmod?

Don't care. Don't care. Do I need to repeat it? I don't care. All I know is that it87 reports lower temperature when CPU is throttled.

...

Quoted 5 lines

Quoted 2 lines

How much Watts does the machine
save power when it is idle using p4-clockmod?

Don't care. Don't care. Do I need to repeat it? I don't care. All I know is that it87 reports lower temperature when CPU is throttled.

How much is it, constantly?

Quoted 6 lines · Thomas Renninger

...

Quoted 5 lines

Quoted 2 lines

How much Watts does the machine
save power when it is idle using p4-clockmod?

Don't care. Don't care. Do I need to repeat it? I don't care. All I know is that it87 reports lower temperature when CPU is throttled.

Quoted 2 lines

How much is it, constantly?

Hmm, it looks ike on ide it is about 78C throttled and 81 unthrottled (I would not pay attention to absolute numbers, I never actually tried to calibrate the readings). So apparently not a lot... For some reason I remember the difference a bit bigger, maybe I was lookig under light load?

Hi,

Quoted 7 lines · Dmitry Torokhov

Quoted 6 lines · Thomas Renninger

...

Quoted 5 lines

Quoted 2 lines

How much Watts does the machine
save power when it is idle using p4-clockmod?

Don't care. Don't care. Do I need to repeat it? I don't care. All I know is that it87 reports lower temperature when CPU is throttled.

Quoted 8 lines

Quoted 2 lines

How much is it, constantly?

Hmm, it looks ike on ide it is about 78C throttled and 81 unthrottled (I would not pay attention to absolute numbers, I never actually tried to calibrate the readings). So apparently not a lot... For some reason I remember the difference a bit bigger, maybe I was lookig under light load?

Probably you were looking under more or less heavy load, for then and only then p4-clockmod makes a difference. (>12.5 load at least)

Thomas: the question whether it saves power when it is idle is not a good criterion -- IIRC, some Intel SpeedStep-capable processors do enter the same low voltage idle state, so on a 100% idle system acpi-cpufreq wouldn't make a difference there either. Similarily, some cpufreq drivers which only do frequency scaling but not frequency and voltage scaling will also only see limited energy savings on 100% idle.

To summarize: If the CPU load is constantly x (0<x<1) within a timeframe, the _CPU_ energy consumption of an ideal system is approximately

- if the CPU does not support frequency or voltage scaling:

	E_none	=  E_idle * (1-x) + E_max * x

- if the CPU supports frequency scaling (with linear energy savings):

	E_fs	=  E_idle + (E_max - E_idle) * x  = E_none

- if the CPU supports throttling:

	E_t	=  E_idle * (1-x) + E_max * x = E_none

- if the CPU supports frequency and voltage scaling (with energy savings to the power of two)

	E_fvs	=  E_idle + (E_max - E_idle) * x^2

This shows that:
1) _if_ idle states work properly, and
2) _if_ the system needs to finish tasks as soon as possible, neither frequency scaling alone nor throttling will get you anything.

Now, let's test whether these two requirements are met:

ad 1) to the Intel folks out here: is C1 entered during throttling, or some deeper sleep level? If it's something deeper, this requirement is not met on my desktop P4 which only offers C1.

ad 2) I can see of two aspects where this is invalid:
- programs which will eat up as much CPU as possible e.g. for even more frames per seconds, and
- thermal side-effects: if the CPU energy consumption surpasses certain thresholds, fans might be needed for cooling, or their rotational speed increased, thereby also increasing the noise, and not to forget the increased hardware wear by increased temperatures...

However, this second requirement alone might be able to be met by software alone, as long as the first requirement -- a proper idle state is entered -- is fulfilled:
(1) Currently, _all_ tasks preempt the idle task -- if there's only one task running in nice level 19, that one gets 100% of the CPU, and the idle thread gets none.
(2) One could now start a task with a very high priority, which schedules its own wakeup, and then calls cpuidle_idle_call(). Caveat: this would not work properly in a high-interrupt system.

Now, such a kernel module would do what -- it would _emulate_ frequency scaling in a software level, while p4-clockmod _emulates_ frequency scaling in hardware. Therefore, the correct place for p4-clockmod and such a generic "I do not want to use my hardware 100%"-module is within the framework which is made for the capabilities they emulate: cpufreq.

Could you explain this in two easy sentences again, why this should not use the throttling interface?

(former /proc/acpi/processor/*/throttling, now somewhere located in sysfs. Also used for passive cooling if no cpufreq is available). Throttling is what this driver is doing and with which it will interfere and slow down the machine to be closed to unresponsive if both (throttling and cpufreq interface) are using it?

Quoted 2 lines · Thomas Renninger

Could you explain this in two easy sentences again, why this should not use the throttling interface?

Because it involves rewriting code for purely aesthetic benefit. I agree that, in an ideal world, p4-clockmod would integrate into the throttling system. But unless someone wants to rewrite it, that doesn't look likely...

Quoted 6 lines

(former /proc/acpi/processor/*/throttling, now somewhere located in sysfs. Also used for passive cooling if no cpufreq is available). Throttling is what this driver is doing and with which it will interfere and slow down the machine to be closed to unresponsive if both (throttling and cpufreq interface) are using it?

The ACPI throttling interface will only be used if the minimum cpufreq state has already been reached.

Users really shouldn't play with the
throttling interface themselves, given its lack of useful functionality.

Remove p4_clockmode driver

The driver is doing throttling which is supposed to be done through another ACPI interface. If both interfaces are used, the machine may get very slow. Remove this driver which should never be used.