[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230619104717.3jvy77y3quou46u3@moria.home.lan>
Date: Mon, 19 Jun 2023 06:47:17 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Mark Rutland <mark.rutland@....com>
Cc: linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-bcachefs@...r.kernel.org,
Kent Overstreet <kent.overstreet@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Uladzislau Rezki <urezki@...il.com>,
Christoph Hellwig <hch@...radead.org>, linux-mm@...ck.org,
Kees Cook <keescook@...omium.org>,
Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH 07/32] mm: Bring back vmalloc_exec
On Mon, Jun 19, 2023 at 10:19:00AM +0100, Mark Rutland wrote:
> On Tue, May 09, 2023 at 12:56:32PM -0400, Kent Overstreet wrote:
> > From: Kent Overstreet <kent.overstreet@...il.com>
> >
> > This is needed for bcachefs, which dynamically generates per-btree node
> > unpack functions.
>
> Much like Kees and Andy, I have concerns with adding new code generators to the
> kernel. Even ignoring the actual code generation, there are a bunch of subtle
> ordering/maintenance/synchronization concerns across architectures, and we
> already have a fair amount of pain with the existing cases.
Look, jits are just not that unusual. I'm not going to be responding to
vague concerns that don't have any actual engineering rational.
> Can you share more detail on how you want to use this?
>
> From a quick scan of your gitweb for the bcachefs-for-upstream branch I
> couldn't spot the relevant patches.
I've already written extensively in this thread.
Powered by blists - more mailing lists