[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2530ba09-73eb-c0fd-5d77-4e6c5a0810a6@huawei.com>
Date: Thu, 14 Aug 2025 17:37:46 +0800
From: Jinjie Ruan <ruanjinjie@...wei.com>
To: Ada Couprie Diaz <ada.coupriediaz@....com>
CC: <catalin.marinas@....com>, <will@...nel.org>, <oleg@...hat.com>,
<sstabellini@...nel.org>, <mark.rutland@....com>, <puranjay@...nel.org>,
<broonie@...nel.org>, <mbenes@...e.cz>, <ryan.roberts@....com>,
<akpm@...ux-foundation.org>, <chenl311@...natelecom.cn>,
<anshuman.khandual@....com>, <kristina.martsenko@....com>,
<liaochang1@...wei.com>, <ardb@...nel.org>, <leitao@...ian.org>,
<linux-arm-kernel@...ts.infradead.org>, <linux-kernel@...r.kernel.org>,
<xen-devel@...ts.xenproject.org>
Subject: Re: [PATCH -next v7 0/7] arm64: entry: Convert to generic irq entry
On 2025/8/12 0:03, Ada Couprie Diaz wrote:
> On 06/08/2025 09:11, Jinjie Ruan wrote:
>
>> On 2025/8/5 23:08, Ada Couprie Diaz wrote:
>>> Hi Jinjie,
>>>
>>> On 29/07/2025 02:54, Jinjie Ruan wrote:
>>>
>>>> Since commit a70e9f647f50 ("entry: Split generic entry into generic
>>>> exception and syscall entry") split the generic entry into generic irq
>>>> entry and generic syscall entry, it is time to convert arm64 to use
>>>> the generic irq entry. And ARM64 will be completely converted to
>>>> generic
>>>> entry in the upcoming patch series.
>>> Note : I had to manually cherry-pick a70e9f647f50 when pulling the
>>> series
>>> on top of the Linux Arm Kernel for-next/core branch, but there might be
>>> something I'm missing here.
>> It seems that it is now in mainline v6.16-rc1 and linux-next but not
>> Linux Arm Kernel for-next/core branch.
> You're right, I misinterpreted the `-next` of the subject, thanks for the
> clarification !
>>> I'll spend some time testing the series now, specifically given patch
>>> 6's
>>> changes, but other than that everything I saw made sense and didn't look
>>> like it would be of concern to me.
>> Thank you for the test and review.
>
> I've spent some time testing the series with a few different
> configurations,
> including PREEMPT_RT, pNMI, various lockup and hang detection options,
> UBSAN, shadow call stack, and various CONFIG_DEBUG_XYZ (focused on locks
> and IRQs), on both hardware (AMD Seattle) and KVM guests.
>
> I tried to generate a diverse set of interrupts (via debug exceptions,
> page faults, perf, kprobes, swapping, OoM) while loading the system with
> different workloads, some generating a lot of context switches : hackbench
> and signaltest from rt-tests[0], and mc-crusher[1], a memcached
> stress-test.
>
> I did not have any issues, nor any warning reported by the various
> debug features during all my hours of testing, so it looks good !
>
> Tested-by: Ada Couprie Diaz <ada.coupriediaz@....com>
Thank you for your comprehensive testing and code review.
>
> Thank you for the series !
> Ada
>
> [0]: https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/
> [1]: https://github.com/memcached/mc-crusher
>
>
Powered by blists - more mailing lists