> "Powersave" means saving power, it doesn't mean saving energy. Your battery holds a fixed amount of energy, not a fixed amount of power. Energy is what matters.

Ignoring everything else, your battery doesn't hold a fixed amount of energy either. Or, if it does, it doesn't deliver a fixed amount. The energy you get out depends on the load. If you draw enough power that it heats the battery, you'll get less energy out. Of course, if you draw so little energy that self discharge becomes significant, you'll get less energy out.

As with the rest of the discussion, there's clearly a balance to be had, but it's hard to make the optimum choice because the systems usually don't know the load profile of (immiment) future work, and there are many systems that interact, and there may be no part of the system that has enough information to make an overall decision. That said, there's clearly been lots of progress on getting quite good results in most scenarios.

> "Powersave" means saving power, it doesn't mean saving energy.

Powersave means saving energy (for a given amount of work), despite the name. Any other behavior is a bug. It usually saves energy by running at a lower frequency, where the frequency/watt and work/joule are better (those aren't the same: there is a region where the first is better but the latter is worse, and you want to avoid that!).

"Race to sleep" isn't binary: it's not a choice between the slowest supported speed and the fastest. Rather, you can select any supported speed. The fastest speeds (usually north of 3 GHz) will almost never provide the best work/joule, regardless of whether you sleep earlier.

> Powersave means saving energy (for a given amount of work), despite the name. Any other behavior is a bug.

  static void cpufreq_gov_powersave_limits(struct cpufreq_policy *policy)
  {
          pr_debug("setting to %u kHz\n", policy->min);
          __cpufreq_driver_target(policy, policy->min, CPUFREQ_RELATION_L);
  }

That's the entire governor. It sets the lowest frequency. This is the documented behavior. Not the frequency with the highest performance per watt. The lowest frequency, period.

Yes, "race to sleep" isn't binary, which is why we have smart modern governors that do a very good job at picking appropriate frequency states - but just as the highest turbo is almost always a bad idea, so is the lowest state, which is what "powersave" does. "ondemand" is more power efficient than "powersave", and "schedutil" even moreso, on modern CPUs.

Right, because the lowest supported frequency is supposed to be the most energy efficient frequency, Feff, at least on Intel chips. I.e. it is the minimum in the joules/work chart.

After all, there's no point running at a lower frequency: those frequencies are always dominated regardless of your time/energy preference, so Intel claims to set Fmin to Feff.

So lowest freq is a good proxy for "I only care about efficiency".

That said, powersave is a bit ambiguous: it's a policy in more than one driver. For example, intel_pstate, the default recommended driver for Intel chips, has powersave and performance governors too, and there powersave is much more sophisticated and can run at high frequencies.

Reality doesn't agree that using the lowest frequency is the most efficient approach, as evidenced by that Lenovo presentation :-)

OK, I actually read the Lenovo paper and it seems fine.

One big difference with what I'm trying to claim is that what I'm saying considers only the power use of the CPU itself: i.e., the thing whose power use varies with frequency. From the CPU manufacturer's point of view, that's all they can really do.

The Lenovo paper is looking at total system power, and the way they calculate efficiency includes the system power in the efficiency calculation. This pushes the efficiency point well above what you'd get from looking at the CPU alone.

Both approaches are right some of the time: on a laptop where the rest of the system is running regardless, you probably want to consider only the CPU power in the efficiency calculation: if your CPU work finishes more quickly it's not going to stop the draw from the screen, wifi chip, etc.

OTOH on a server if you size your fleet based on the total work, you should really use total power since if your work takes less time you need fewer total servers (or fewer cloud CPU hours, etc) so the system power is also saved.