Messages in this thread | | | Date | Thu, 23 Jan 2020 22:40:09 +0100 | From | Neil Horman <> | Subject | Re: 答复: [RFC] irq: Sk ip printin g irq when desc->action is null even if any_count is not zero |
| |
On Thu, Jan 23, 2020 at 01:34:33PM +0100, Thomas Gleixner wrote: > Chao, > > "liuchao (CR)" <liuchao173@huawei.com> writes: > > On Thu, Jan 23, 2020 at 03:29AM +0800, Neil Horman wrote: > >> > I'm not opposed to suppress the output, but I really want the opinion > >> > of the irqbalance maintainers on that. > > > > Irqbalance is an example. I mean, when this happens, users who cat /proc/interrupts > > may be confused about where the interrupt came from and what it was used for. > > People who use Linux may not understand the principle of this. They are not sure > > whether this is a problem of the system or not. > > Well, this has been that way for 20+ years and so far nobody got > confused. If it's not documented then we should do so. > > >> Actually, irqbalance ignores the trailing irq name (or it should at least), so you > >> should be able to drop that portion of /proc/irqbalance, though I cant speak for > >> any other users of it. > > > > If irq isn't removed from /proc/interrups, it will still be parsed in > > collect_full_irq_list and parse_proc_interrupts. > > Sure, and why is that a problem? Again, this is really historic behaviour. > > > irq_name is used in guess_arm_irq_hints. > > That's a problem of guess_arm_irq_hints() then. > > Again, I'm not against supressing such lines in general, but I want to > make sure that no tool depends on that information. > I think it probably makes sense to just keep it then. I'm not sure I see it as hurting anything to keep it around.
Neil
> Thanks, > > tglx >
| |