linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: Oleg Nesterov <oleg@redhat.com>, Kees Cook <kees@kernel.org>,
	Andy Lutomirski <luto@amacapital.net>,
	Will Drewry <wad@chromium.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Jinjie Ruan <ruanjinjie@huawei.com>,
	Arnd Bergmann <arnd@arndb.de>, Ard Biesheuvel <ardb@kernel.org>,
	Al Viro <viro@zeniv.linux.org.uk>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH RFC 00/28] ARM: Switch to generic entry
Date: Thu, 10 Oct 2024 12:55:32 +0100	[thread overview]
Message-ID: <ZwfAtJfNm95sXgo8@shell.armlinux.org.uk> (raw)
In-Reply-To: <20241010-arm-generic-entry-v1-0-b94f451d087b@linaro.org>

On Thu, Oct 10, 2024 at 01:33:38PM +0200, Linus Walleij wrote:
> This patch series converts a slew of ARM assembly into the
> corresponding C code, step by step moving the codebase
> closer to the expectations of the generic entry code,
> and as a last step switches ARM over to the generic
> entry code.

I haven't looked at the series yet, but I guess we're throwing away
all the effort I put in to make stuff like syscalls as fast as
possible.

So the question is... do we want performance, or do we want generic
(and slower) code?

It seems insane to me that we spend time micro-optimising things like
memcpy, memset, divide routines, but then go and throw away performance
that applications actually rely upon, such as syscall performance.

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


  parent reply	other threads:[~2024-10-10 12:27 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-10 11:33 [PATCH RFC 00/28] ARM: Switch to generic entry Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 01/28] ARM: Prepare includes for " Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 02/28] ARM: ptrace: Split report_syscall() Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 03/28] ARM: entry: Skip ret_slow_syscall label Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 04/28] ARM: process: Rewrite ret_from_fork i C Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 05/28] ARM: process: Remove local restart Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 06/28] ARM: entry: Invoke syscalls using C Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 07/28] ARM: entry: Rewrite two asm calls in C Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 08/28] ARM: entry: Move trace entry to C function Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 09/28] ARM: entry: save the syscall sp in thread_info Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 10/28] ARM: entry: move all tracing invocation to C Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 11/28] ARM: entry: Merge the common and trace entry code Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 12/28] ARM: entry: Rename syscall invocation Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 13/28] ARM: entry: Create user_mode_enter/exit Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 14/28] ARM: entry: Drop trace argument from usr_entry macro Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 15/28] ARM: entry: Separate call path for syscall SWI entry Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 16/28] ARM: entry: Drop argument to asm_irqentry macros Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 17/28] ARM: entry: Implement syscall_exit_to_user_mode() Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 18/28] ARM: entry: Drop the superfast ret_fast_syscall Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 19/28] ARM: entry: Remove fast and offset register restore Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 20/28] ARM: entry: Untangle ret_fast_syscall/to_user Linus Walleij
2024-10-10 11:33 ` [PATCH RFC 21/28] ARM: entry: Do not double-call exit functions Linus Walleij
2024-10-10 11:34 ` [PATCH RFC 22/28] ARM: entry: Move work processing to C Linus Walleij
2024-10-10 11:34 ` [PATCH RFC 23/28] ARM: entry: Stop exiting syscalls like IRQs Linus Walleij
2024-10-10 11:34 ` [PATCH RFC 24/28] ARM: entry: Complete syscall and IRQ transition to C Linus Walleij
2024-10-10 11:34 ` [PATCH RFC 25/28] ARM: entry: Create irqentry calls from kernel mode Linus Walleij
2024-10-10 11:34 ` [PATCH RFC 26/28] ARM: entry: Move in-kernel hardirq tracing to C Linus Walleij
2024-10-10 11:34 ` [PATCH RFC 27/28] ARM: entry: Add FIQ/NMI C callbacks Linus Walleij
2024-10-10 11:34 ` [PATCH RFC 28/28] ARM: entry: Convert to generic entry Linus Walleij
2024-10-10 11:55 ` Russell King (Oracle) [this message]
2024-10-10 12:11   ` [PATCH RFC 00/28] ARM: Switch " Linus Walleij
2024-10-10 13:07     ` Russell King (Oracle)

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=ZwfAtJfNm95sXgo8@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=frederic@kernel.org \
    --cc=kees@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=oleg@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=ruanjinjie@huawei.com \
    --cc=viro@zeniv.linux.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).