Andriy Gapon <[email protected]> wrote:
>>> 3. Try to make FreeBSD smarter with respect to dynamically changing
>>> C-states. I
>>> think it would be useful if we received a devd notifications about
>>> C-state
>>> reconfiguration. Then we could execute /etc/rc.d/power_profile to
>>> account for the
>>> new configuration.
>>
>> This would be the most useful option.
>
> I agree! :)
Actually, I have a simpler fix. We could allow setting hw.acpi.cx_lowest
to any value, including states that are not currently present. Then,
on updates to available Cx states, our ACPI code will automatically
set dev.cpu.N.cx_lowest to the closest valid value without the need
for a separate power_profile invocation.
Here's the diff:
--- acpi_cpu.c.orig 2011-07-05 19:50:31.000000000 +0000
+++ acpi_cpu.c 2011-07-06 17:23:16.000000000 +0000
@@ -1194,7 +1194,7 @@
if (strlen(state) < 2 || toupper(state[0]) != 'C')
return (EINVAL);
val = (int) strtol(state + 1, NULL, 10) - 1;
- if (val < 0 || val > cpu_cx_count - 1)
+ if (val < 0)
return (EINVAL);
cpu_cx_lowest = val;
You can even simplify power_profile with this change:
--- power_profile.orig 2011-07-06 18:39:27.000000000 +0000
+++ power_profile 2011-07-06 18:40:20.000000000 +0000
@@ -81,8 +81,7 @@
# Set the various sysctls based on the profile's values.
node="hw.acpi.cpu.cx_lowest"
highest_value="C1"
-lowest_value="`(sysctl -n dev.cpu.0.cx_supported | \
- awk '{ print "C" split($0, a) }' -) 2> /dev/null`"
+lowest_value="C99"
eval value=\$${profile}_cx_lowest
sysctl_set
>> Here's what I tried (trivial diff, sending inline):
>>
>> [...]
>>
>> This generally works, except that power_profile is executed multiple
>> times (the event is generated once per core, and when it is triggered
>> by plugging the power cord, ACPI ACAD is reported at the same time
>> thus resulting in one more power_profile execution).
>
> At this time and for this purpose I would probably send the notification only
> if
> global cx_lowest value changes as we do not do per-CPU power profiles.
Yes, this makes sense.
> Also, I think that cpu_cx_count is not the best parameter for notification.
> For per-cpu events I would rather use CPU ID. For global events, it may makes
> sense to use /subsystem/ value of "CPU" and then discriminate various types
> of CPU
> events via /notify/. E.g. notify=0 could be used to indicate Cx changes.
> Maybe
> we will have more ACPI CPU events in the future.
Seems reasonable too, but this won't be necessary for my case if
the above change will be implemented.
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "[email protected]"
