Create new LED trigger for CPU activity
PATCH 1/1 Create new LED trigger for CPU activity
This patch creates a new LED trigger that triggers whenever the CPU is active. It can be configured with module parameters to trigger on any combination of user, nice, system, or iowait time, and defaults to including user and system time but not nice or iowait time. I've tested it a bit, and it seems to work, but no guarantees. It's diffed against 2.6.17-git25.
drivers/leds/Kconfig +7 -0
@@ -93,6 +93,13 @@ This allows LEDs to be controlled by IDE disk activity. If unsure, say Y. +config LEDS_TRIGGER_CPU + tristate "LED CPU Trigger" + depends LEDS_TRIGGERS + help + This allows LEDs to be controlled by CPU activity. + If unsure, say Y. + config LEDS_TRIGGER_HEARTBEAT tristate "LED Heartbeat Trigger" depends LEDS_TRIGGERS
drivers/leds/ledtrig-cpu.c +146 -0
146 lines not on this page · raw message
drivers/leds/Makefile +1 -0
@@ -16,4 +16,5 @@ # LED Triggers obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK) += ledtrig-ide-disk.o +obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
Hi!
Quoted 8 lines
This patch creates a new LED trigger that triggers whenever the CPU is active. It can be configured with module parameters to trigger on any combination of user, nice, system, or iowait time, and defaults to including user and system time but not nice or iowait time. I've tested it a bit, and it seems to work, but no guarantees. It's diffed against 2.6.17-git25.
Signed-off-by Thomas Tuttle <[email protected]>
I like the idea.. CPU usage led is very useful, and old led system actually provided it. But...
Quoted 6 lines
+/*
+ * ChangeLog:
+ *
+ * Revision 3 (2006/06/06):
+ * Added module parameters to configure which time is counted as CPU
+ * activity. (thanks to Andrew Morton)
Quoted 8 lines
+ *
+ * Revision 2 (2006/06/05):
+ * Diffed against 2.6.17-git25 instead of 2.6.17.1.
+ * Fixed several code style issues (thanks to Randy Dunlap)
+ *
+ * Revision 1 (2006/06/05):
+ * Initial patch submitted.
+ */
Please don't include changelogs in sources.
Quoted 1 line
+#define
UPDATE_INTERVAL(5) /* delay between updates, in ms */
Polling every 5 msec is going to cost _lot_ of juice. Is there a better way?
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
(Reply comes after ChangeLog and Signed-off-by.)
This patch creates a new LED trigger that triggers whenever the CPU is active. It can be configured with module parameters to trigger on any combination of user, nice, system, or iowait time, and defaults to including user and system time but not nice or iowait time. I've tested it a bit, and it seems to work, but no guarantees. It's diffed against 2.6.17-git25.
On July 06 at 19:52 EDT, Pavel Machek hastily scribbled:
Quoted 1 line
Please don't include changelogs in sources.
Okay. I've attached an updated patch.
Quoted 3 lines
Quoted 1 line
+#define
UPDATE_INTERVAL(5) /* delay between updates, in ms */Polling every 5 msec is going to cost _lot_ of juice. Is there a better way?
This is a sticky issue. My first idea was to wire something into schedule() so that when the idle process was selected, it would switch the LED off, and when another process was selected, it would switch it on, but that would have been really hairy. In addition, it wouldn't allow the trigger to differentiate between user, system, nice, and iowait time, which it can now.
I don't think it's that much of a performance hit (the calculations are fairly short, and a trigger event isn't sent unless the LED state changed), but if you disagree, I can do a couple of things:
* Lower the frequency to every 10ms (100Hz) or 40ms (25Hz). This will reduce the performance hit, but also reduce the accuracy of the LED. Right now, it flickers nicely when the CPU is somewhat busy, but if I lower the frequency, it will more often stay on rather than flickering. I guess it's a matter of taste.
* Make the frequency configurable by a module parameter. This way, users who don't mind the performance hit can increase the speed, and those who do mind can lower it.
* Try to hook it in to the scheduler, so it actually knows the moment the CPU idles or starts doing something. This will make it impossible to differentiate user/system time, and hard to differentiate user/nice time.
I personally think it's okay as it is, but I'm willing to make changes if you prefer.
--Thomas Tuttle
drivers/leds/Kconfig +7 -0
@@ -93,6 +93,13 @@ This allows LEDs to be controlled by IDE disk activity. If unsure, say Y. +config LEDS_TRIGGER_CPU + tristate "LED CPU Trigger" + depends LEDS_TRIGGERS + help + This allows LEDs to be controlled by CPU activity. + If unsure, say Y. + config LEDS_TRIGGER_HEARTBEAT tristate "LED Heartbeat Trigger" depends LEDS_TRIGGERS
drivers/leds/ledtrig-cpu.c +131 -0
131 lines not on this page · raw message
drivers/leds/Makefile +1 -0
@@ -16,4 +16,5 @@ # LED Triggers obj-$(CONFIG_LEDS_TRIGGER_TIMER) += ledtrig-timer.o obj-$(CONFIG_LEDS_TRIGGER_IDE_DISK) += ledtrig-ide-disk.o +obj-$(CONFIG_LEDS_TRIGGER_CPU) += ledtrig-cpu.o obj-$(CONFIG_LEDS_TRIGGER_HEARTBEAT) += ledtrig-heartbeat.o
Quoted 10 lines · Thomas Tuttle
On July 06 at 19:52 EDT, Pavel Machek hastily scribbled:
Quoted 3 lines
Quoted 1 line
+#define
UPDATE_INTERVAL(5) /* delay between updates, in ms */Polling every 5 msec is going to cost _lot_ of juice. Is there a better way?
This is a sticky issue. My first idea was to wire something into
schedule()so that when the idle process was selected, it would switch the LED off, and when another process was selected, it would switch it on, but that would have been really hairy. In addition, it wouldn't allow the trigger to differentiate between user, system, nice, and iowait time, which it can now.
CPU activity was always going to be desired but tricky. At the moment, I know of at least three ways people have implemented it, yours, one from the NSLU2 people and the existing old ARM LED infrastructure.
For the old ARM approach, see arch/arm/kernel/process.c NSLU2 patch:
http://trac.nslu2-linux.org/kernel/browser/trunk/patches/2.6.17/50-leds-arm-cpu-activity.patch
These other two patches are good in that they hook into the idle handler and only do things at cpu idle time rather than running every 5ms. Running every 5ms is not going to work well on my arm handheld (for example). The existing ARM code is the simplest but doesn't give the amount of configuration the NSLU2 people want.
I've just been asked for a trigger with the same behaviour as the old ARM LED code to complicate matters (then we have no reason people can't port their LED code over to the new interface). For that reason I'll be writing a trigger to emulate the old ARM approach.
Quoted 3 lines
I don't think it's that much of a performance hit (the calculations are fairly short, and a trigger event isn't sent unless the LED state changed), but if you disagree, I can do a couple of things:
Running every 5ms like this *is* going to hit performance, particularly on lower CPU powered devices.
Quoted 5 lines
* Lower the frequency to every 10ms (100Hz) or 40ms (25Hz). This will reduce the performance hit, but also reduce the accuracy of the LED. Right now, it flickers nicely when the CPU is somewhat busy, but if I lower the frequency, it will more often stay on rather than flickering. I guess it's a matter of taste.
At the moment you check (used_cputime > 0). If you compared that to some small value instead of zero, you might reduce the always on threshold. Finding that threshold might be tricky though.
Quoted 4 lines
* Try to hook it in to the scheduler, so it actually knows the moment the CPU idles or starts doing something. This will make it impossible to differentiate user/system time, and hard to differentiate user/nice time.
Is that differentiation useful in practise? (I'll have to try it and see I guess)
There is no right answer here. I want to test the different approaches before any of these triggers get into mainline as we don't want a great stack of different cpu activity triggers. Perhaps you could do the same and see how you feel about the other approaches.
Richard