On Thu, 2006-07-06 at 21:58 -0400, Thomas Tuttle wrote:
> On July 06 at 19:52 EDT, Pavel Machek hastily scribbled:
> > > +#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.
> 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.
> * 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.
> * 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
