All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <valentin.schneider@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>
Subject: Re: [RFC PATCH v2 00/10] irqchip/irq-gic: Optimize masking by leveraging EOImode=1
Date: Tue, 01 Jun 2021 11:25:01 +0100	[thread overview]
Message-ID: <87tumhg9vm.mognet@arm.com> (raw)
In-Reply-To: <87zgwgs9x0.wl-maz@kernel.org>

On 27/05/21 12:17, Marc Zyngier wrote:
> On Tue, 25 May 2021 18:32:45 +0100,
> Valentin Schneider <valentin.schneider@arm.com> wrote:
>> I've tested this on my Ampere eMAG, which uncovered "fun" interactions with
>> the MSI domains. Did the same trick as the Juno with the pl011.
>>
>> pNMIs cause said eMAG to freeze, but that's true even without my patches. I
>> did try them out under QEMU+KVM and that looked fine, although that means I
>> only got to test EOImode=0. I'll try to dig into this when I get some more
>> cycles.
>
> That's interesting/worrying. As far as I remember, this machine uses
> GIC500, which is a well known quantity. If pNMIs are causing issues,
> that'd probably be a CPU interface problem. Can you elaborate on how
> you tried to test that part? Just using the below benchmark?
>

Not even that, it would hang somewhere at boot. Julien suggested offline
that it might be a problem with the secondaries' PMR initial value, but I
really never got to do dig into it.

>>
>> Performance impact
>> ==================
>>
>> Benchmark
>> +++++++++
>>
>> Finding a benchmark that leverages a force-threaded IRQ has proved to be
>> somewhat of a pain, so I crafted my own. It's a bit daft, but so are most
>> benchmarks (though this one might win a prize).
>
> I love it (and wrote similar hacks in my time)! :D

Yay!

> Can you put that up
> somewhere so that I can run the same test on my own zoo and find out
> how it fares?
>

The setup part is really fugly and I was too ashamed of it to link it in
the cover letter; for ACPI I could simply use acpi_register_gsi() since
that uses the right domain by default, but for DT I ended up adding a DT
entry and a match table.

I'll see about unifying this and I'll send it out your way.

_______________________________________________
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: Marc Zyngier <maz@kernel.org>
Cc: linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Thomas Gleixner <tglx@linutronix.de>,
	Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>
Subject: Re: [RFC PATCH v2 00/10] irqchip/irq-gic: Optimize masking by leveraging EOImode=1
Date: Tue, 01 Jun 2021 11:25:01 +0100	[thread overview]
Message-ID: <87tumhg9vm.mognet@arm.com> (raw)
In-Reply-To: <87zgwgs9x0.wl-maz@kernel.org>

On 27/05/21 12:17, Marc Zyngier wrote:
> On Tue, 25 May 2021 18:32:45 +0100,
> Valentin Schneider <valentin.schneider@arm.com> wrote:
>> I've tested this on my Ampere eMAG, which uncovered "fun" interactions with
>> the MSI domains. Did the same trick as the Juno with the pl011.
>>
>> pNMIs cause said eMAG to freeze, but that's true even without my patches. I
>> did try them out under QEMU+KVM and that looked fine, although that means I
>> only got to test EOImode=0. I'll try to dig into this when I get some more
>> cycles.
>
> That's interesting/worrying. As far as I remember, this machine uses
> GIC500, which is a well known quantity. If pNMIs are causing issues,
> that'd probably be a CPU interface problem. Can you elaborate on how
> you tried to test that part? Just using the below benchmark?
>

Not even that, it would hang somewhere at boot. Julien suggested offline
that it might be a problem with the secondaries' PMR initial value, but I
really never got to do dig into it.

>>
>> Performance impact
>> ==================
>>
>> Benchmark
>> +++++++++
>>
>> Finding a benchmark that leverages a force-threaded IRQ has proved to be
>> somewhat of a pain, so I crafted my own. It's a bit daft, but so are most
>> benchmarks (though this one might win a prize).
>
> I love it (and wrote similar hacks in my time)! :D

Yay!

> Can you put that up
> somewhere so that I can run the same test on my own zoo and find out
> how it fares?
>

The setup part is really fugly and I was too ashamed of it to link it in
the cover letter; for ACPI I could simply use acpi_register_gsi() since
that uses the right domain by default, but for DT I ended up adding a DT
entry and a match table.

I'll see about unifying this and I'll send it out your way.

  reply	other threads:[~2021-06-01 10:27 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-25 17:32 [RFC PATCH v2 00/10] irqchip/irq-gic: Optimize masking by leveraging EOImode=1 Valentin Schneider
2021-05-25 17:32 ` Valentin Schneider
2021-05-25 17:32 ` [RFC PATCH v2 01/10] genirq: Add chip flag to denote automatic IRQ (un)masking Valentin Schneider
2021-05-25 17:32   ` Valentin Schneider
2021-05-25 17:32 ` [RFC PATCH v2 02/10] genirq: Define irq_ack() and irq_eoi() helpers Valentin Schneider
2021-05-25 17:32   ` Valentin Schneider
2021-05-25 20:54   ` kernel test robot
2021-05-27 10:55   ` Marc Zyngier
2021-05-27 10:55     ` Marc Zyngier
2021-05-27 10:58     ` Marc Zyngier
2021-05-27 10:58       ` Marc Zyngier
2021-06-01 10:25       ` Valentin Schneider
2021-06-01 10:25         ` Valentin Schneider
2021-05-25 17:32 ` [RFC PATCH v2 03/10] genirq: Employ ack_irq() and eoi_irq() where relevant Valentin Schneider
2021-05-25 17:32   ` Valentin Schneider
2021-05-25 17:32 ` [RFC PATCH v2 04/10] genirq: Add handle_strict_flow_irq() flow handler Valentin Schneider
2021-05-25 17:32   ` Valentin Schneider
2021-05-25 17:32 ` [RFC PATCH v2 05/10] genirq: Let purely flow-masked ONESHOT irqs through unmask_threaded_irq() Valentin Schneider
2021-05-25 17:32   ` Valentin Schneider
2021-05-25 17:32 ` [RFC PATCH v2 06/10] genirq: Don't mask IRQ within flow handler if IRQ is flow-masked Valentin Schneider
2021-05-25 17:32   ` Valentin Schneider
2021-05-25 17:32 ` [RFC PATCH v2 07/10] genirq, irq-gic-v3: Make NMI flow handlers use ->irq_ack() if available Valentin Schneider
2021-05-25 17:32   ` Valentin Schneider
2021-05-25 17:32 ` [RFC PATCH v2 08/10] irqchip/gic-v3-its: Use irq_chip_ack_parent() Valentin Schneider
2021-05-25 17:32   ` Valentin Schneider
2021-05-27 12:17   ` Marc Zyngier
2021-05-27 12:17     ` Marc Zyngier
2021-06-01 10:25     ` Valentin Schneider
2021-06-01 10:25       ` Valentin Schneider
2021-05-25 17:32 ` [RFC PATCH v2 09/10] irqchip/gic: Convert to handle_strict_flow_irq() Valentin Schneider
2021-05-25 17:32   ` Valentin Schneider
2021-05-27 12:21   ` Marc Zyngier
2021-05-27 12:21     ` Marc Zyngier
2021-06-01 10:25     ` Valentin Schneider
2021-06-01 10:25       ` Valentin Schneider
2021-06-15 15:20       ` Valentin Schneider
2021-06-15 15:20         ` Valentin Schneider
2021-05-25 17:32 ` [RFC PATCH v2 10/10] irqchip/gic-v3: " Valentin Schneider
2021-05-25 17:32   ` Valentin Schneider
2021-05-25 17:34 ` [RFC PATCH v2 00/10] irqchip/irq-gic: Optimize masking by leveraging EOImode=1 Valentin Schneider
2021-05-25 17:34   ` Valentin Schneider
2021-05-27 11:17 ` Marc Zyngier
2021-05-27 11:17   ` Marc Zyngier
2021-06-01 10:25   ` Valentin Schneider [this message]
2021-06-01 10:25     ` Valentin Schneider
2021-06-03 15:32     ` Valentin Schneider
2021-06-03 15:32       ` Valentin Schneider
2021-06-08 15:29     ` Marc Zyngier
2021-06-08 15:29       ` Marc Zyngier
2021-06-08 17:58       ` Lorenzo Pieralisi
2021-06-08 17:58         ` Lorenzo Pieralisi

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=87tumhg9vm.mognet@arm.com \
    --to=valentin.schneider@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=maz@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=vincenzo.frascino@arm.com \
    /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.