Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1314425

Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings

From Thomas Gleixner <tglx@linutronix.de>
Newsgroups linux.kernel
Subject Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings
Date 2016-01-21 20:00 +0100
Message-ID <qTsCD-Pl-23@gated-at.bofh.it> (permalink)
References (2 earlier) <qT6iK-2se-3@gated-at.bofh.it> <qT759-2KF-25@gated-at.bofh.it> <qTkc1-3tc-1@gated-at.bofh.it> <qTnWi-5YM-25@gated-at.bofh.it> <qTofE-6n5-3@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Thu, 21 Jan 2016, Daniel Lezcano wrote:
> On 01/21/2016 02:52 PM, Thomas Gleixner wrote:

> > And why would that thing care about shared interruts at all? It's a legacy
> > burden and I really don't see a reason why that new thing which is
> > targeted on modern hardware should deal with them. Just treat them as a
> > single interrupt for now and be done with it.
> 
> If the shared interrupts are only related to old hardware, these ones
> shouldn't have cpuidle, hence there is no need to enable the irq timings. So
> you are right in this case and we can keep the feature simple.
> 
> On a other hand, Peter sent three examples of /proc/interrupts with shared
> interrupts. I don't know how old are the platforms and what are they, but it
> seems the shared irq are still used.

Well, its still there on x86 but slowly on the way out. What I meant with
legacy burden is, that the HW people finally got the idea that shared
interrupts are a horrible concept.

So we are seing them go away. My laptop (not the newest thingy) doesn't have
them anymore. Most devices use MSI now, except for the holdouts:

  0:         20          0          0          0   IO-APIC-edge      timer
  1:          1          1          5          3   IO-APIC-edge      i8042
  8:          5          6          0          4   IO-APIC-edge      rtc0
  9:        294       1231        118        318   IO-APIC-fasteoi   acpi
 12:         96       1748         55         76   IO-APIC-edge      i8042
 18:          0          0          0          0   IO-APIC  18-fasteoi   i801_smbus
 23:         11         12          8         51   IO-APIC  23-fasteoi   ehci_hcd:usb1

My latest server toy still has one shared entry:

   18-fasteoi   ehci_hcd:usb1, ehci_hcd:usb2, i801_smbus

which is just a complete braindamage on the hardware side. There are a
gazillion of free interrupt lines on that beast and of course they must route
3 devices to the same line.

We really should ignore that sillyness and if people complain, make them
complain to their HW vendor. That's the only way this crap will go away.

If we just keep on supporting this completely pointless nonsense the HW folks
will just not fix it.

We've been successful in the past to 'educate' hw people by making features
not available for mindless designs.

In this case we still support the feature, but it might be suboptimal. The
real interesting ports on that platform are MSI anyway, so I really couldn't
care less.

I have no idea how wide spread the shared nonsense is on the relevant ARM
platforms, but you might be able to figure that out faster than me.

Thanks,

	tglx

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle  period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-18 14:30 +0100
  Re: [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle  period Thomas Gleixner <tglx@linutronix.de> - 2016-01-20 16:50 +0100
    [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
      Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-01-20 18:50 +0100
        Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 19:50 +0100
        Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 11:10 +0100
      Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:10 +0100
        Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-01-20 20:20 +0100
          Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:40 +0100
      Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:40 +0100
      Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:50 +0100
        Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-01-20 21:00 +0100
          Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 21:30 +0100
      Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Thomas Gleixner <tglx@linutronix.de> - 2016-01-20 21:00 +0100
        Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 15:00 +0100
          Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Thomas Gleixner <tglx@linutronix.de> - 2016-01-21 15:20 +0100
    [RFC V2 0/2] IRQ based next prediction Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
    [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
      Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-01-20 21:20 +0100
        Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle  period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 14:10 +0100
    [RFC V2 0/2] IRQ based next prediction Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
      [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
        Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-20 19:00 +0100
          Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 10:30 +0100
            Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-21 11:30 +0100
        Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:10 +0100
          Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-20 21:00 +0100
            Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-01-20 21:10 +0100
            Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Peter Zijlstra <peterz@infradead.org> - 2016-01-20 21:30 +0100
              Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-20 21:30 +0100
            Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 11:00 +0100
              Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Peter Zijlstra <peterz@infradead.org> - 2016-01-21 11:10 +0100
                Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 13:40 +0100
                Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-21 21:30 +0100
              Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-21 15:00 +0100
                Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 15:20 +0100
                Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-21 20:00 +0100
                Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Peter Zijlstra <peterz@infradead.org> - 2016-01-22 11:20 +0100
          Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 10:30 +0100
        Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:30 +0100
          Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 11:00 +0100
      [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100

csiph-web