lkml.org 
[lkml]   [2020]   [Jun]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v2 15/17] arm64: Remove custom IRQ stat accounting
On 2020-06-27 00:15, Valentin Schneider wrote:
> On 26/06/20 12:58, Marc Zyngier wrote:
>> On 2020-06-25 19:26, Valentin Schneider wrote:
>>> On 24/06/20 20:58, Marc Zyngier wrote:
>>>> @@ -801,26 +802,15 @@ void show_ipi_list(struct seq_file *p, int
>>>> prec)
>>>> unsigned int cpu, i;
>>>>
>>>> for (i = 0; i < NR_IPI; i++) {
>>>> + unsigned int irq = irq_desc_get_irq(ipi_desc[i]);
>>>> seq_printf(p, "%*s%u:%s", prec - 1, "IPI", i,
>>>> prec >= 4 ? " " : "");
>>>> for_each_online_cpu(cpu)
>>>> - seq_printf(p, "%10u ",
>>>> - __get_irq_stat(cpu, ipi_irqs[i]));
>>>> + seq_printf(p, "%10u ", kstat_irqs_cpu(irq, cpu));
>>>> seq_printf(p, " %s\n", ipi_types[i]);
>>>
>>> How attached are we to that custom IPI printout? AIUI we *could* give
>>> them
>>> a "prettier" name in request_percpu_irq() and let the standard procfs
>>> printout take the wheel.
>>
>> I wish. Unfortunately, /proc/interrupts is likely to be considered
>> ABI,
>> and I'm really worried to change this (see what happened last time we
>> tried to update /proc/cpuinfo to be less braindead...).
>>
>
> Hmph, it's borderline here I think: we're not introducing a new field
> or
> format in the file, so any tool that can parse /proc/interrupts can
> parse
> the IPIs if they are formatted like the other "regular" interrupts. But
> then said tool could die in flames when not seeing the special IPI
> fields
> because sturdiness is overrated :(

Which is exactly what I'm worried about. People do stupid things,
and stupidity becomes ABI. I hate luserspace.

M.
--
Jazz is not dead. It just smells funny...

\
 
 \ /
  Last update: 2020-06-27 13:44    [W:0.165 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site