Messages in this thread | | | Date | Sun, 28 Sep 2008 21:42:01 +0200 | From | Pavel Machek <> | Subject | Re: [PATCH 1/1] SGI X86 UV: Provide a System Activity Indicator driver |
| |
> Another relevant point is that I will be adding a bit more functionality > to disable the timer interrupt on truly "idle" cpus (like have been idle > for some amount of seconds). We would then use the "exit from idle" > callback to reestablish the timer interrupt. [This would allow them to > enter power down states if appropriate.]
Should you look at nohz instead of reinventing it?
> > As i suggested in my previous mail about this topic, a low-frequency > > sampling method should be used instead, to indicate system status. I > > thought the leds drivers have all that in place already. > > It is low frequency (once per second), this is just setting what's to > be sampled. > > As I mentioned, this is not for LED displays (human readable), it's for the > system controller to monitor how all parts of the system are running, and > this one is just the cpu parts. The LED driver approach would have me > registering 4096 led devices, with all their callbacks, 4096 strings saying > "LED0001", etc., and I still cannot associate a specific register bit > (AKA LED if that's what it was), with a specific cpu using the LED driver. > > The LED driver is fine for a couple of blinking lights indicating overall > system activity, disk activity, etc. (Btw, I did not see a network trigger, > or a paging trigger, or an out of memory trigger, or some other things that > might be useful for real time monitoring of the system.)
...so add them...
> But the LED driver has way more overhead than needed for this simple application. >
So overhead from led driver is not okay, while overhead from messing with idle loop is okay? Interesting... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
| |