Re: [PATCH v2 0/6] arm/arm64: Allow the rescheduling IPI to bypass irq_enter/exit

2021-03-08 Thread Yuichi Ito
Hi Marc, Mark

> Mark is working on this, I believe. I'll let him comment on the current 
> state of things.

I understand.
Mark, Could you tell me current state?

Thanks,

Yuichi Ito



Re: [PATCH v2 0/6] arm/arm64: Allow the rescheduling IPI to bypass irq_enter/exit

2021-03-01 Thread Marc Zyngier

On 2021-03-01 00:39, ito-yui...@fujitsu.com wrote:

Hi Marc,

I plan to add NMI patches which enables IPI_CPU_CRASH_STOP IPI as 
pseudo-NMI[1].

But I know need to resolve the instrumentation issues before that. I
think need to moving arm64 entry code over to the generic entry
code(kernel/entry/common.c) for that, is this right?

Can you tell me current status?
Let me know if there's anything I can do to help.


Mark is working on this, I believe. I'll let him comment on the current 
state of things.


Thanks,

M.
--
Jazz is not dead. It just smells funny...


RE: [PATCH v2 0/6] arm/arm64: Allow the rescheduling IPI to bypass irq_enter/exit

2021-02-28 Thread ito-yui...@fujitsu.com
Hi Marc,

I plan to add NMI patches which enables IPI_CPU_CRASH_STOP IPI as pseudo-NMI[1].
But I know need to resolve the instrumentation issues before that. I think need 
to moving arm64 entry code over to the generic entry 
code(kernel/entry/common.c) for that, is this right?

Can you tell me current status?
Let me know if there's anything I can do to help.

[1]https://lore.kernel.org/lkml/20201104080539.3205889-1-ito-yui...@fujitsu.com/

Thanks,

Yuichi Ito



[PATCH v2 0/6] arm/arm64: Allow the rescheduling IPI to bypass irq_enter/exit

2020-11-24 Thread Marc Zyngier
This is the second version of my earlier series [1], which aims at
fixing (or papering over, depending on how you look at things) a
performance regression seen on arm64 for reched IPI heavy workloads
(such as "perf bench sched pipe").

As eloquently described by Thomas in his earlier replies [2], the
current situation is less than ideal on most architecture except x86,
and my conclusion is that what was broken in 5.9 wouldn't be more
broken in 5.10 with these patches (and addresses the performance
regression).

Needless to say, I intend to try and help fixing the issues Thomas
mentioned, and I believe that Mark (cc'd) already has something that
could be used as a healthy starting point (Mark, do correct me if I
misrepresented your work).

Thanks,

M.

* From v1:
  - Added a new __irq_modify_status() helper
  - Renamed IRQ_NAKED to IRQ_RAW
  - Renamed IRQ_HIDDEN to IRQ_IPI
  - Applied the same workaround to 32bit ARM for completeness

[1] https://lore.kernel.org/r/20201101131430.257038-1-...@kernel.org/
[2] https://lore.kernel.org/r/87lfewnmdz@nanos.tec.linutronix.de/

Marc Zyngier (6):
  genirq: Add __irq_modify_status() helper to clear/set special flags
  genirq: Allow an interrupt to be marked as 'raw'
  arm64: Mark the recheduling IPI as raw interrupt
  arm: Mark the recheduling IPI as raw interrupt
  genirq: Drop IRQ_HIDDEN from IRQF_MODIFY_MASK
  genirq: Rename IRQ_HIDDEN to IRQ_IPI

 arch/arm/Kconfig|  1 +
 arch/arm/kernel/smp.c   |  6 +-
 arch/arm64/Kconfig  |  1 +
 arch/arm64/kernel/smp.c |  6 +-
 include/linux/irq.h | 11 ---
 kernel/irq/Kconfig  |  3 +++
 kernel/irq/chip.c   | 12 ++--
 kernel/irq/debugfs.c|  3 ++-
 kernel/irq/irqdesc.c| 17 -
 kernel/irq/proc.c   |  2 +-
 kernel/irq/settings.h   | 33 +++--
 11 files changed, 75 insertions(+), 20 deletions(-)

-- 
2.28.0