Re: [PATCH]new ACPI processor driver to force CPUs idle

Len Brown
2009-06-24T17:21:01Z

> Any thermal facility that doesn't take cpusets into account, or worse
> destroys user policy (the hotplug road), is a full stop in my book.
>
> Is similar to the saying the customer is always right, sure the admin
> can indeed configure the machine so that any thermal policy is indeed
> doomed to fail, and in that case I would print some warnings into syslog
> and let the machine die of thermal overload -- not our problem.
>
> The thing is, the admin configures it in a way, and then expects it to
> work like that. If any random event can void the guarantees what good
> are they?
>
> Now, if ACPI-4.0 is so broken that it simply cannot support a sane
> thermal model, then I suggest we simply not support this feature and
> hope they will grow clue for 4.1 and try again next time.

Peter,
ACPI is just the messenger here - user policy in in charge,
and everybody agrees, user policy is always right.

The policy may be a thermal cap to deal with thermal emergencies
as gracefully as possible, or it may be an electrical cap to
prevent a rack from approaching the limits of the provisioned
electrical supply.

This isn't about a brain dead administrator, doomed thermal policy,
or a broken ACPI spec. This mechanism is about trying to maintain
uptime in the face of thermal emergencies, and spending limited
electrical provisioning dollars to match, rather than grosely exceed,
maximum machine room requirements.

Do you have any fundamental issues with these goals?
Are we agreement that they are worth goals?

The forced-idle technique is employed after the processors have
all already been forced to their lowest performance P-state
and the power/thermal problem has not been resolved.

No, this isn't a happy scenario, we are definately impacting
performance. However, we are trying to impact system performance
as little as possible while saving as much energy as possible.

After P-states are exhausted and the problem is not resolved,
the rack (via ACPI) asks Linux to idle a processor.
Linux has full freedom to choose which processor.
If the condition does not get resolved, the rack will ask us
to offline more processors.

If this technique fails, the rack will throttle the processors
down as low as 1/16th of their lowest performance P-state.
Yes, that is about 100MHz on most multi GHz systems...

If that fails, the entire system is powered-off.

Obviously, the approach is to impact performance as little as possible
while impacting energy consumption as much as possible. Use the most
efficieint means first, and resort to increasingly invasive measures
as necessary...

I think we all agree that we must not break the administrator's
cpuset policy if we are asked to force a core to be idle -- for
whent the emergency is over,the system should return to normal
and bear not permanent scars.

The simplest thing that comes to mind is to declare a system
with cpusets or binding fundamentally incompatible with
forced idle, and to skip that technique and let the hardware
throttle all the processor clocks with T-states.

However, on aggregate, forced-idle is a more efficient way
to save energy, as idle on today's processors is highly optimized.

So if you can suggest how we can force processors to be idle
even when cpusets and binding are present in a system,
that would be great.

thanks,
-Len Brown, Intel Open Source Technology Center