Re: [PATCH v3 0/3] arm64: entry: Convert to generic entry

["Russell King (Oracle)" <linux@armlinux.org.uk>]

On Thu, Oct 17, 2024 at 04:25:36PM +0100, Mark Rutland wrote:
> Hi,
> 
> On Sat, Jun 29, 2024 at 04:55:58PM +0800, Jinjie Ruan wrote:
> > Currently, x86, Riscv, Loongarch use the generic entry. Convert arm64
> > to use the generic entry infrastructure from kernel/entry/*. The generic
> > entry makes maintainers' work easier and codes more elegant, which aslo
> > removed a lot of duplicate code.
> 
> >  arch/arm64/Kconfig                    |   1 +
> >  arch/arm64/include/asm/entry-common.h | 172 ++++++++++++
> >  arch/arm64/include/asm/ptrace.h       |   5 +
> >  arch/arm64/include/asm/stacktrace.h   |   5 +-
> >  arch/arm64/include/asm/syscall.h      |   6 +-
> >  arch/arm64/include/asm/thread_info.h  |  23 +-
> >  arch/arm64/kernel/entry-common.c      | 368 +++++---------------------
> >  arch/arm64/kernel/ptrace.c            |  90 -------
> >  arch/arm64/kernel/signal.c            |   3 +-
> >  arch/arm64/kernel/syscall.c           |  18 +-
> >  include/linux/entry-common.h          |  90 +++++++
> >  include/linux/thread_info.h           |  13 +
> >  kernel/entry/common.c                 |  37 +--
> >  13 files changed, 395 insertions(+), 436 deletions(-)
> >  create mode 100644 arch/arm64/include/asm/entry-common.h
> 
> Looking at this I have a few concerns, which I've tried to explain
> below.

One concern I notice Mark didn't mention is (and I've made this same
point in response to LinusW's series doing similar for 32-bit ARM)
is... we need to quantify what the impact is of making these changes.

Historically, people have worked hard to make the overhead from
syscalls as low as possible - if one looks at the x86 architecture,
Linux first started off using int $0x80 to deliver syscalls to the
kernel. Later CPUs invented sysenter and syscall instructions which
I guess result in increased performance over the old int $0x80
approach.

syscall entry/exit times are one of those trivial things to measure,
most commonly done by seeing how many getpid() calls one can make
to the kernel in a defined period of time - and it's one of those
measurements people consider (rightly or wrongly) to be a measure
of the system performance.

When one considers that the majority of interactions userspace has
with the kernel involve syscalls, one can see why this is an
important path to be as performant as possible.

So, I think it's important to always quantify what the impact is of
any major change to the kernel entry/exit paths - it's all part of
properly evaluating whether the change makes sense.

If switching to generic code causes a significant degredation in
performance, then that needs to be investigated and fixed - not
waited for until someone pops up and eventually says "hey, that
change to use the generic code resulted in our systems becoming
much less performant!" six or twelve months down the road.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!