Re: [PATCH 1/1] SGI X86 UV: Provide a System Activity Indicator driver

[Mike Travis]

Ingo Molnar wrote:
> * Pavel Machek <pavel@xxxxxxx> wrote:
> 
>> On Fri 2008-10-24 04:19:04, Mike Travis wrote:
>>> [Ingo - could you let me know what's holding up this driver?
>>> Thanks!, Mike]
>> I thought that...
>>
>>  > +static __init void uv_scir_register_cpu_notifier(void)
>>> +{
>>> +	hotcpu_notifier(uv_scir_cpu_notify, 0);
>>> +	idle_notifier_register(&uv_idle_notifier);
>>> +}
>> ...Ingo said that idle_notifier_register is deprecated and going away?
> 
> yes, but i suspect Mike noticed that i acked Len's use of idle notifiers 
> in the ACPI tree, and now he wants to refresh this discussion?
> 
> i cannot really believe why anyone would want to slow down the from-idle 
> hotpath in such a lame way:
> 
> +       } else if (action == IDLE_END) {
> +
> +               uv_hub_info->scir.state |= SCIR_CPU_ACTIVITY;
> +               uv_hub_info->scir.idle_off += elapsed;
> +               uv_hub_info->scir.last = jiffies;
> +       }
> 
> with such a lame and low-res timestamp:
> 
> +       unsigned long elapsed = jiffies - uv_hub_info->scir.last;
> 
> it's an absolutely pointless act of adding overhead. Just use a regular 
> timer mechanism to update uv_hub_info->scir.idle_off.

I do use the timer mechanism (once per second) to update the scir state.
Unfortunately, the state is *always* not idle during the timer callback
(since we are actively executing), so I needed some way of knowing the
idle state prior to the timer callback.  The idle callback is only used
to record the amount of time this cpu's been idle during the last second
so on the once per second interrupt, I can determine if this cpu was more,
or less idle during that same time period.

The hardware saves the last 64 seconds for diagnostic purposes so this is
not meant to be a high-res indication but a longer term cpu history (along
with the other error records recorded, like memory/cpu/bus faults, etc.)
The System Controller copies these records into the system logs.

Also, this is only on a UV system, I'm not introducing any overhead for
any other x86_64 systems.

Thanks,
Mike
--
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/