All of lore.kernel.org
 help / color / mirror / Atom feed
From: Samir M <samir@linux.ibm.com>
To: Mukesh Kumar Chaurasiya <mkchauras@linux.ibm.com>,
	maddy@linux.ibm.com, mpe@ellerman.id.au, npiggin@gmail.com,
	christophe.leroy@csgroup.eu, oleg@redhat.com, kees@kernel.org,
	luto@amacapital.net, wad@chromium.org, mchauras@linux.ibm.com,
	thuth@redhat.com, sshegde@linux.ibm.com,
	akpm@linux-foundation.org, macro@orcam.me.uk, ldv@strace.io,
	deller@gmx.de, charlie@rivosinc.com, bigeasy@linutronix.de,
	segher@kernel.crashing.org, thomas.weissschuh@linutronix.de,
	menglong8.dong@gmail.com, ankur.a.arora@oracle.com,
	peterz@infradead.org, namcao@linutronix.de, tglx@linutronix.de,
	kan.liang@linux.intel.com, mingo@kernel.org,
	atrajeev@linux.vnet.ibm.com, mark.barnett@arm.com,
	coltonlewis@google.com, rppt@kernel.org,
	linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/8] Generic IRQ entry/exit support for powerpc
Date: Tue, 11 Nov 2025 10:39:31 +0530	[thread overview]
Message-ID: <a0af8e59-6828-4e12-b0a2-bc426df97b0e@linux.ibm.com> (raw)
In-Reply-To: <f7fe2fb8-4538-42a7-985a-a68eb8da7395@linux.ibm.com>


On 11/11/25 10:09 am, Samir M wrote:
> On 02/11/25 5:23 pm, Mukesh Kumar Chaurasiya wrote:
>> Adding support for the generic irq entry/exit handling for PowerPC. The
>> goal is to bring PowerPC in line with other architectures that already
>> use the common irq entry infrastructure, reducing duplicated code and
>> making it easier to share future changes in entry/exit paths.
>>
>> This is slightly tested of ppc64le and ppc32.
>>
>> The performance benchmarks from perf bench basic syscall are below:
>>
>> | Metric     | W/O Generic Framework | With Generic Framework | Change |
>> | ---------- | --------------------- | ---------------------- | ------ |
>> | Total time | 0.939 [sec]           | 0.938 [sec]            | ~0%    |
>> | usecs/op   | 0.093900              | 0.093882               | ~0%    |
>> | ops/sec    | 1,06,49,615           | 1,06,51,725            | ~0%    |
>>
>> Thats very close to performance earlier with arch specific handling.
>>
>> Tests done:
>>   - Build and boot on ppc64le pseries.
>>   - Build and boot on ppc64le powernv8 powernv9 powernv10.
>>   - Build and boot on ppc32.
>>   - Performance benchmark done with perf syscall basic on pseries.
>>
>> Changelog:
>>
>> RFC -> PATCH
>>   - Fix for ppc32 spitting out kuap lock warnings.
>>   - ppc64le powernv8 crash fix.
>>   - Review comments incorporated from previous RFC.
>> RFC 
>> https://lore.kernel.org/all/20250908210235.137300-2-mchauras@linux.ibm.com/
>>
>> Mukesh Kumar Chaurasiya (8):
>>    powerpc: rename arch_irq_disabled_regs
>>    powerpc: Prepare to build with generic entry/exit framework
>>    powerpc: introduce arch_enter_from_user_mode
>>    powerpc: Introduce syscall exit arch functions
>>    powerpc: add exit_flags field in pt_regs
>>    powerpc: Prepare for IRQ entry exit
>>    powerpc: Enable IRQ generic entry/exit path.
>>    powerpc: Enable Generic Entry/Exit for syscalls.
>>
>>   arch/powerpc/Kconfig                    |   2 +
>>   arch/powerpc/include/asm/entry-common.h | 539 ++++++++++++++++++++++++
>>   arch/powerpc/include/asm/hw_irq.h       |   4 +-
>>   arch/powerpc/include/asm/interrupt.h    | 401 +++---------------
>>   arch/powerpc/include/asm/ptrace.h       |   3 +
>>   arch/powerpc/include/asm/stacktrace.h   |   6 +
>>   arch/powerpc/include/asm/syscall.h      |   5 +
>>   arch/powerpc/include/asm/thread_info.h  |   1 +
>>   arch/powerpc/include/uapi/asm/ptrace.h  |  14 +-
>>   arch/powerpc/kernel/asm-offsets.c       |   1 +
>>   arch/powerpc/kernel/interrupt.c         | 258 +++---------
>>   arch/powerpc/kernel/ptrace/ptrace.c     | 142 +------
>>   arch/powerpc/kernel/signal.c            |   8 +
>>   arch/powerpc/kernel/syscall.c           | 119 +-----
>>   arch/powerpc/kernel/traps.c             |   2 +-
>>   arch/powerpc/kernel/watchdog.c          |   2 +-
>>   arch/powerpc/perf/core-book3s.c         |   2 +-
>>   17 files changed, 693 insertions(+), 816 deletions(-)
>>   create mode 100644 arch/powerpc/include/asm/entry-common.h
>>
> Hi,
>
> I have reviewed and tested the generic IRQ entry/exist patch series. 
> Below are my observations:
>
> 
Test Coverage

> • Successfully ran LTP (specially syscall) and entire LTP test suite, 
> without observing any regressions or issues related to the 
> implementation.
>
> 
System Configuration

> • CPUs: 160

> • Kernel: v6.18.0-rc1+

> • Processor mode: Shared (uncapped)
>
> 
Performance Evaluation

> • Conducted benchmarking using perf bench syscall basic -l and 
> hackbench.

> • No functional regressions observed, and results were consistent with 
> expectations.
>
>     •    Results for perf bench syscall**Loops = 100,000**
> **Loops = 100,000**
> | Metric       | W/O Generic Framework      | With Generic Framework  
>   | Improvement |
> |----------|-----------------------:|-----------------------:|------------:| 
>
> | usecs/op   |              0.125328              | 0.128839         
> |     ~-2.80% |
> | ops/sec     |             7,979,645              |  7,762,047       
>     |     ~-2.73% |
>
> **Loops = 1,000,000**
> | Metric        | W/O Generic Framework         | With Generic 
> Framework             | Improvement |
> |----------|-----------------------:|-----------------------:|------------:| 
>
> | usecs/op   |              0.125015              | 0.127885         
> |     ~-2.30% |
> | ops/sec     |             7,999,051              |  7,819,546       
>     |     ~-2.24% |
>
> **Loops = 10,000,000**
> | Metric        | W/O Generic Framework    | With Generic Framework   
>  | Improvement |
> |----------|-----------------------:|-----------------------:|------------:| 
>
> | usecs/op   |              0.124613              | 0.127426         
> |     ~-2.26% |
> | ops/sec     |             8,024,827              |  7,847,735       
>     |     ~-2.21% |
>
> **Overall (aggregated across all runs)**
> | Metric         | W/O Generic Framework   | With Generic Framework   
>  | Improvement |
> | ---------- | 
> ---------------------:|-----------------------:|------------:|
> | Total time    |           1.384 [sec]            |  1.415 [sec]      
>          |     ~-2.27% |
> | usecs/op     |              0.124656            | 0.127480         
> |     ~-2.27% |
> | ops/sec       |             8,022,098            |  7,844,423       
>     |     ~-2.21% |
>
> A 2% performance degradation was observed with the perf bench syscall.
>
>     •    Results for hackbench
>
> | Metric        | W/O Generic Framework    | With Generic Framework   
> | Improvement |
> |----------|---------------------- 
> :|-----------------------:|------------:|
> | Min Time   | 142.055 (sec).                   | 141.699 (sec)       
>        | 0.25%
> | Max Time  | 143.791 (sec).                   | 143.206 (sec)         
>    | 0.41%
> | Avg Time   | 142.925 (sec)                    | 142.472 (sec)       
>        | 0.32%
>
> So overall 0.3 % improvement is observed across 10 runs.
>
> Please add below tag for the patch set.
> 
Tested-by: Samir M <samir@linux.ibm.com>
> Thank You !!
>
>
> Regards,
> Samir.
>
Hi,

Apologies for the earlier email. The benchmark results table was not 
properly formatted in that version, so I am re-sending the results below 
for clarity.

I have reviewed and tested the generic IRQ entry/exist patch series. 
Below are my observations:


Test Coverage
• Successfully ran LTP (specially syscall) and entire LTP test suite, 
without observing any regressions or issues related to the implementation.


System Configuration
• CPUs: 160
• Kernel: v6.18.0-rc1+
• Processor mode: Shared (uncapped)


Performance Evaluation
• Conducted benchmarking using perf bench syscall basic -l and hackbench.
• No functional regressions observed, and results were consistent with 
expectations.

     •    Results for perf bench syscall

Loops = 100,000
+-----------+------------------------+------------------------+------------+
| Metric      | W/O Generic Framework     | With Generic Framework    | 
Improvement |
+-----------+------------------------+------------------------+------------+
| usecs/op  |           0.125328                 |  0.128839            
        | ~-2.80%     |
| ops/sec    |            7,979,645               |  7,762,047          
         | ~-2.73%     |
+-----------+------------------------+------------------------+------------+

Loops = 1,000,000
+-----------+------------------------+------------------------+------------+
| Metric      | W/O Generic Framework  | With Generic Framework | 
Improvement |
+-----------+------------------------+------------------------+------------+
| usecs/op  |          0.125015               |        0.127885         
         | ~-2.30%     |
| ops/sec    |          7,999,051              |        7,819,546       
            | ~-2.24%     |
+-----------+------------------------+------------------------+------------+

Loops = 10,000,000
+-----------+------------------------+------------------------+------------+
| Metric      | W/O Generic Framework  | With Generic Framework  | 
Improvement |
+-----------+------------------------+------------------------+------------+
| usecs/op  |         0.124613                |        0.127426         
         | ~-2.26%     |
| ops/sec    |         8,024,827               |        7,847,735       
            | ~-2.21%     |
+-----------+------------------------+------------------------+------------+

Overall (aggregated across all runs)
+-------------+------------------------+------------------------+----------+
| Metric         | W/O Generic Framework  | With Generic Framework | 
Improvement |
+-------------+------------------------+------------------------+----------+
| Total time   |        1.384 [sec]               |         1.415 [sec]  
               | ~-2.27%     |
| usecs/op     |        0.124656                 | 0.127480              
      | ~-2.27%     |
| ops/sec       |        8,022,098                | 7,844,423            
       | ~-2.21%     |
+-------------+------------------------+------------------------+----------+
A 2% performance degradation was observed with the perf bench syscall.

     •    Results for hackbench

+-----------+---------------------------+---------------------------+------+
| Metric        | W/O Generic Framework     | With Generic Framework    
| Improvement |
+-----------+---------------------------+---------------------------+------+
| Min Time  |    142.055 (sec)                     |       141.699 
(sec)             |  +0.25%      |
| Max Time  |   143.791 (sec)                     |       143.206 (sec)  
             |  +0.41%      |
| Avg Time  |   142.925 (sec)                      |      142.472 (sec)  
             |  +0.32%      |
+-----------+---------------------------+---------------------------+------+

So overall 0.3 % improvement is observed across 10 runs.

Please add below tag for the patch set.


Tested-by: Samir M <samir@linux.ibm.com>
Thank You !!


Regards,
Samir.



      reply	other threads:[~2025-11-11  5:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-02 11:53 [PATCH 0/8] Generic IRQ entry/exit support for powerpc Mukesh Kumar Chaurasiya
2025-11-02 11:53 ` [PATCH 1/8] powerpc: rename arch_irq_disabled_regs Mukesh Kumar Chaurasiya
2025-11-02 11:53 ` [PATCH 2/8] powerpc: Prepare to build with generic entry/exit framework Mukesh Kumar Chaurasiya
2025-11-02 11:53 ` [PATCH 3/8] powerpc: introduce arch_enter_from_user_mode Mukesh Kumar Chaurasiya
2025-11-02 11:53 ` [PATCH 4/8] powerpc: Introduce syscall exit arch functions Mukesh Kumar Chaurasiya
2025-11-02 11:53 ` [PATCH 5/8] powerpc: add exit_flags field in pt_regs Mukesh Kumar Chaurasiya
2025-11-02 11:53 ` [PATCH 6/8] powerpc: Prepare for IRQ entry exit Mukesh Kumar Chaurasiya
2025-11-02 11:53 ` [PATCH 7/8] powerpc: Enable IRQ generic entry/exit path Mukesh Kumar Chaurasiya
2025-11-02 11:53 ` [PATCH 8/8] powerpc: Enable Generic Entry/Exit for syscalls Mukesh Kumar Chaurasiya
2025-11-08 12:23   ` kernel test robot
2025-11-07 16:23 ` [PATCH 0/8] Generic IRQ entry/exit support for powerpc Shrikanth Hegde
2025-11-19 17:57   ` Thomas Gleixner
2025-11-21  5:48     ` Mukesh Kumar Chaurasiya
2025-11-10  9:12 ` Samir Alamshaha Mulani
2025-11-11  4:39 ` Samir M
2025-11-11  5:09   ` Samir M [this message]

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=a0af8e59-6828-4e12-b0a2-bc426df97b0e@linux.ibm.com \
    --to=samir@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=ankur.a.arora@oracle.com \
    --cc=atrajeev@linux.vnet.ibm.com \
    --cc=bigeasy@linutronix.de \
    --cc=charlie@rivosinc.com \
    --cc=christophe.leroy@csgroup.eu \
    --cc=coltonlewis@google.com \
    --cc=deller@gmx.de \
    --cc=kan.liang@linux.intel.com \
    --cc=kees@kernel.org \
    --cc=ldv@strace.io \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=luto@amacapital.net \
    --cc=macro@orcam.me.uk \
    --cc=maddy@linux.ibm.com \
    --cc=mark.barnett@arm.com \
    --cc=mchauras@linux.ibm.com \
    --cc=menglong8.dong@gmail.com \
    --cc=mingo@kernel.org \
    --cc=mkchauras@linux.ibm.com \
    --cc=mpe@ellerman.id.au \
    --cc=namcao@linutronix.de \
    --cc=npiggin@gmail.com \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rppt@kernel.org \
    --cc=segher@kernel.crashing.org \
    --cc=sshegde@linux.ibm.com \
    --cc=tglx@linutronix.de \
    --cc=thomas.weissschuh@linutronix.de \
    --cc=thuth@redhat.com \
    --cc=wad@chromium.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.