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

Groups > linux.kernel > #1313309

Re: [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period

From Thomas Gleixner <tglx@linutronix.de>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period
Date 2016-01-20 16:50 +0100
Message-ID <qT3bb-7a-5@gated-at.bofh.it> (permalink)
References <qNYc9-2Y2-7@gated-at.bofh.it> <qNYc9-2Y2-5@gated-at.bofh.it> <qOHsB-gc-7@gated-at.bofh.it> <qSi2C-1bm-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw

On Mon, 18 Jan 2016, Daniel Lezcano wrote:
> On 01/08/2016 04:43 PM, Thomas Gleixner wrote:
> > The above is completely unprotected against interrupts being setup or even
> > freed concurrently.
> > 
> > Aside of that, you call that setup function in setup_irq for each action()
> > and
> > here you call it only for the first one.
> 
> I went through the different comments and almost finished the changes but I
> think the 'register_ops' approach, which happens after some irq were setup,
> introduces some useless complexity and because of the desc lock section, the
> ops can't do memory allocation.

You can't protect that with desc_lock. You need to take the sparse_irq_lock,
which is a mutex, to protect the irq desc walk.

> Before going further, I am wondering if declaring the irq_timings_ops
> statically (read without 'register_ops' - hence without a init time
> dependency) and calling the init/free ops from alloc_desc/free_desc wouldn't
> be cleaner and simpler.

Then you don't need those ops at all. You can make it simple function calls,
which get compiled out if that stuff is not enabled.

Thanks,

	tglx

Back to linux.kernel | Previous | Next — Previous 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