lkml.org 
[lkml]   [2008]   [Sep]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] SGI X86 UV: Provide a System Activity Indicator driver
Ingo Molnar wrote:
> * Mike Travis <travis@sgi.com> wrote:
>
>> arch/x86/kernel/genx2apic_uv_x.c | 138 +++++++++++++++++++++++++++++++++++++++
>> include/asm-x86/uv/uv_hub.h | 62 +++++++++++++++++
>
> hm, why is this in genx2apic_uv_x.c, not a separate file?
>
>> + idle_notifier_register(&uv_idle_notifier);
>
> no, we really dont want such overhead in an idle notifier. (those
> interfaces will go away)

Hi Ingo,

The overhead is very low and I've not been able to figure out how to
"estimate" per cpu usage without tons more code (duplicating "top" in
the kernel.) The actual I/O (well O ;-) is once per second. The other
important point is this is only on an SGI UV system, so no other systems
are affected. Because of this, I'm a bit confused by your objection.

I tried a couple of other approaches, but because the timer wakeup
causes the idle state to be exited, it's difficult to determine if
the cpu was idle before the timer interrupt. (I even tried putting a
"wasidle" in the pda to check the idle state prior to the last exit
from idle, but this did not appear to be reliable.) The idle callback
solves this rather nicely.

Here's the same code that's been in ia64 for quite a while:

arch/ia64/sn/kernel/setup.c:
void __init sn_setup(char **cmdline_p)
{
...
ia64_mark_idle = &snidle;

arch/ia64/kernel/process.c:
cpu_idle (void)
{
void (*mark_idle)(int) = ia64_mark_idle;
...

if (mark_idle)
(*mark_idle)(1);

(The x86 callback approach is much cleaner.)

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.]

>
> 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.)

But the LED driver has way more overhead than needed for this simple application.

Thanks,
Mike


\
 
 \ /
  Last update: 2008-09-22 16:45    [W:0.084 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site