All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rich Felker <dalias@libc.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH] irqchip/jcore: fix lost per-cpu interrupts
Date: Sun, 09 Oct 2016 22:06:16 +0000	[thread overview]
Message-ID: <20161009220616.GD19318@brightrain.aerifal.cx> (raw)
In-Reply-To: <alpine.DEB.2.20.1610092121460.7166@nanos>

On Sun, Oct 09, 2016 at 09:23:58PM +0200, Thomas Gleixner wrote:
> On Sun, 9 Oct 2016, Rich Felker wrote:
> > On Sun, Oct 09, 2016 at 01:03:10PM +0200, Thomas Gleixner wrote:
> > My preference would just be to keep the branch, but with your improved
> > version that doesn't need a function call:
> > 
> > 	irqd_is_per_cpu(irq_desc_get_irq_data(desc))
> >
> > While there is some overhead testing this condition every time, I can
> > probably come up with several better places to look for a ~10 cycle
> > improvement in the irq code path without imposing new requirements on
> > the DT bindings.
> 
> Fair enough. Your call.

Thanks.

> > As noted in my followup to the clocksource stall thread, there's also
> > a possibility that it might make sense to consider the current
> > behavior of having non-percpu irqs bound to a particular cpu as part
> > of what's required by the compatible tag, in which case
> > handle_percpu_irq or something similar/equivalent might be suitable
> > for both the percpu and non-percpu cases. I don't understand the irq
> > subsystem well enough to insist on that but I think it's worth
> > consideration since it looks like it would improve performance of
> > non-percpu interrupts a bit.
> 
> Well, you can use handle_percpu_irq() for your device interrupts if you
> guarantee at the hardware level that there is no reentrancy.

Reentrancy is possible of course if the kernel enables irqs during the
irq handler. Is not doing so a stable part of the kernel irq
subsystem? My understanding is that modern kernels keep irqs disabled
for the full duration of (hard) irq handlers.

> Once you make
> the hardware capable of delivering them on either core the picture changes.

*nod* Perhaps if/when we do that, the path of least resistence would
be to adjust the irq numbering so that percpu (i.e., hard-routed to a
particular cpu) and global irqs (deliverable on any core) are in
different ranges and the existing kernel frameworks work.

Rich

WARNING: multiple messages have this Message-ID (diff)
From: Rich Felker <dalias@libc.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org, linux-sh@vger.kernel.org,
	Jason Cooper <jason@lakedaemon.net>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Daniel Lezcano <daniel.lezcano@linaro.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: [PATCH] irqchip/jcore: fix lost per-cpu interrupts
Date: Sun, 9 Oct 2016 18:06:16 -0400	[thread overview]
Message-ID: <20161009220616.GD19318@brightrain.aerifal.cx> (raw)
In-Reply-To: <alpine.DEB.2.20.1610092121460.7166@nanos>

On Sun, Oct 09, 2016 at 09:23:58PM +0200, Thomas Gleixner wrote:
> On Sun, 9 Oct 2016, Rich Felker wrote:
> > On Sun, Oct 09, 2016 at 01:03:10PM +0200, Thomas Gleixner wrote:
> > My preference would just be to keep the branch, but with your improved
> > version that doesn't need a function call:
> > 
> > 	irqd_is_per_cpu(irq_desc_get_irq_data(desc))
> >
> > While there is some overhead testing this condition every time, I can
> > probably come up with several better places to look for a ~10 cycle
> > improvement in the irq code path without imposing new requirements on
> > the DT bindings.
> 
> Fair enough. Your call.

Thanks.

> > As noted in my followup to the clocksource stall thread, there's also
> > a possibility that it might make sense to consider the current
> > behavior of having non-percpu irqs bound to a particular cpu as part
> > of what's required by the compatible tag, in which case
> > handle_percpu_irq or something similar/equivalent might be suitable
> > for both the percpu and non-percpu cases. I don't understand the irq
> > subsystem well enough to insist on that but I think it's worth
> > consideration since it looks like it would improve performance of
> > non-percpu interrupts a bit.
> 
> Well, you can use handle_percpu_irq() for your device interrupts if you
> guarantee at the hardware level that there is no reentrancy.

Reentrancy is possible of course if the kernel enables irqs during the
irq handler. Is not doing so a stable part of the kernel irq
subsystem? My understanding is that modern kernels keep irqs disabled
for the full duration of (hard) irq handlers.

> Once you make
> the hardware capable of delivering them on either core the picture changes.

*nod* Perhaps if/when we do that, the path of least resistence would
be to adjust the irq numbering so that percpu (i.e., hard-routed to a
particular cpu) and global irqs (deliverable on any core) are in
different ranges and the existing kernel frameworks work.

Rich

  reply	other threads:[~2016-10-09 22:06 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-09  5:59 [PATCH] irqchip/jcore: fix lost per-cpu interrupts Rich Felker
2016-10-09 11:03 ` Thomas Gleixner
2016-10-09 11:03   ` Thomas Gleixner
2016-10-09 14:47   ` Rich Felker
2016-10-09 14:47     ` Rich Felker
2016-10-09 19:23     ` Thomas Gleixner
2016-10-09 19:23       ` Thomas Gleixner
2016-10-09 22:06       ` Rich Felker [this message]
2016-10-09 22:06         ` Rich Felker
2016-10-09 23:27         ` Thomas Gleixner
2016-10-09 23:27           ` Thomas Gleixner
2016-10-11 15:21       ` Rich Felker
2016-10-11 15:21         ` Rich Felker
2016-10-12  8:18         ` Thomas Gleixner
2016-10-12  8:18           ` Thomas Gleixner
2016-10-12 16:35           ` Rich Felker
2016-10-12 16:35             ` Rich Felker
2016-10-12 20:34             ` Paul E. McKenney
2016-10-12 20:34               ` Paul E. McKenney
2016-10-12 22:19               ` Rich Felker
2016-10-12 22:19                 ` Rich Felker
2016-10-13  7:30                 ` Paul E. McKenney
2016-10-13  7:30                   ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161009220616.GD19318@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=daniel.lezcano@linaro.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.