Re: [RFC] maximum latency tracking infrastructure
From: Arjan van de Ven
Date: Thu Aug 24 2006 - 17:17:41 EST
Jesse Barnes wrote:
On Thursday, August 24, 2006 10:41 am, Arjan van de Ven wrote:
The reason for adding this infrastructure is that power management in
the idle loop needs to make a tradeoff between latency and power
savings (deeper power save modes have a longer latency to running code
again).
What if a processor was already in a sleep state when a call to
set_acceptable_latency() latency occurs?
there's nothing sane that can be done in that case; any wake up already will cause the unwanted latency!
A premature wakeup is only making it happen *now*, but now is as inconvenient a time as any...
(in fact it may be a worst case time scenario, say, an audio interrupt...)
Should there be a callback so
they can be woken up? A callback would also allow ACPI to tell the
user "disabling C3 because of device <foo>" or somesuch, which might be
nice.
printk'ing would be evil, changes like this will be "semi frequent", like every time you start
or stop playing audio. What ACPI could easily do is indicate in /proc/acpi/processor/*/power
that a state will not be reachable because it violates the latency constraints. That would
be entirely reasonable.
Also, should subsystems have the ability to set a lower bound on
latency? That would mean set_acceptable_latency() could fail,
indicating that the user should buy a better device or a system with
better realtime guarantees, which is also valuable info.
While it's valuable info.. there is nothing you can DO about it...
While the kernel can even do a latency of 1us by just not going into C1 even... so the kernel
CAN honor it, even if it thinks it might not be a good idea. Can you give a more concrete example
of a situation where you think your idea would be useful?
Greetings,
Arjan van de Ven
-
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/