All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Android Kernel Team <kernel-team@android.com>,
	Marc Zyngier <maz@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Will Deacon <will@kernel.org>,
	LAK <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 0/2] arm64: Allow the rescheduling IPI to bypass irq_enter/exit
Date: Tue, 10 Nov 2020 15:48:58 +0000	[thread overview]
Message-ID: <jhjpn4lxlel.mognet@arm.com> (raw)
In-Reply-To: <19286daf276f46aa@fake-msgid>


On 01/01/70 01:00, Valentin Schneider wrote:
> On 10/11/20 13:03, Peter Zijlstra wrote:
>> On Mon, Nov 02, 2020 at 10:30:50AM +0000, Valentin Schneider wrote:
>>
>>> Now, I'd like to pen exactly why we think it's okay to forgo irq_{enter,
>>> exit}() for that one IRQ and not any other.
>>
>> Thomas already said a few words on this, but basically scheduler_ipi()
>> is a NOP (*almost*), the IPI has no body. All it does is tickle the
>> return-from-interrupt path. So any setup and tear-down done for the
>> non-existing body is a waste of time.

Gotcha.

The pedant in me thinks this makes it more of a handler property than an
IRQ one, but I don't see a nice way to e.g. have this as a flag passed to
__request_percpu_irq() and not have it usable by random modules.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Valentin Schneider <valentin.schneider@arm.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Marc Zyngier <maz@kernel.org>,
	LAK <linux-arm-kernel@lists.infradead.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Will Deacon <will@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH 0/2] arm64: Allow the rescheduling IPI to bypass irq_enter/exit
Date: Tue, 10 Nov 2020 15:48:58 +0000	[thread overview]
Message-ID: <jhjpn4lxlel.mognet@arm.com> (raw)
In-Reply-To: <19286daf276f46aa@fake-msgid>


On 01/01/70 01:00, Valentin Schneider wrote:
> On 10/11/20 13:03, Peter Zijlstra wrote:
>> On Mon, Nov 02, 2020 at 10:30:50AM +0000, Valentin Schneider wrote:
>>
>>> Now, I'd like to pen exactly why we think it's okay to forgo irq_{enter,
>>> exit}() for that one IRQ and not any other.
>>
>> Thomas already said a few words on this, but basically scheduler_ipi()
>> is a NOP (*almost*), the IPI has no body. All it does is tickle the
>> return-from-interrupt path. So any setup and tear-down done for the
>> non-existing body is a waste of time.

Gotcha.

The pedant in me thinks this makes it more of a handler property than an
IRQ one, but I don't see a nice way to e.g. have this as a flag passed to
__request_percpu_irq() and not have it usable by random modules.

  parent reply	other threads:[~2020-11-10 15:49 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-01 13:14 [PATCH 0/2] arm64: Allow the rescheduling IPI to bypass irq_enter/exit Marc Zyngier
2020-11-01 13:14 ` Marc Zyngier
2020-11-01 13:14 ` [PATCH 1/2] genirq: Allow an interrupt to be marked as 'naked' Marc Zyngier
2020-11-01 13:14   ` Marc Zyngier
2020-11-01 14:33   ` David Laight
2020-11-01 14:33     ` David Laight
2020-11-01 13:14 ` [PATCH 2/2] arm64: Mark the recheduling IPI as naked interrupt Marc Zyngier
2020-11-01 13:14   ` Marc Zyngier
2020-11-01 14:30 ` [PATCH 0/2] arm64: Allow the rescheduling IPI to bypass irq_enter/exit David Laight
2020-11-01 14:30   ` David Laight
2020-11-02 10:30 ` Valentin Schneider
2020-11-02 10:30   ` Valentin Schneider
2020-11-10 13:03   ` Peter Zijlstra
2020-11-10 13:03     ` Peter Zijlstra
     [not found]     ` <19286daf276f46aa@fake-msgid>
2020-11-10 15:48       ` Valentin Schneider [this message]
2020-11-10 15:48         ` Valentin Schneider
2020-11-03 20:32 ` Thomas Gleixner
2020-11-03 20:32   ` Thomas Gleixner
2020-11-20  9:20   ` Marc Zyngier
2020-11-20  9:20     ` Marc Zyngier
2020-11-20 14:17     ` Thomas Gleixner
2020-11-20 14:17       ` Thomas Gleixner
2020-11-22 16:13       ` Marc Zyngier
2020-11-22 16:13         ` Marc Zyngier

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=jhjpn4lxlel.mognet@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=catalin.marinas@arm.com \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.org \
    /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.