linux-kernel - Re: [RFC] optimize cost of inter-process communication

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <b22117bf-6b2c-4a98-8a40-48163c1e25d9@intel.com>
Date: Wed, 30 Apr 2025 07:03:12 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Jiadong Sun <sunjiadong.lff@...edance.com>, luto@...nel.org,
 juri.lelli@...hat.com, vincent.guittot@...aro.org, akpm@...ux-foundation.org
Cc: x86@...nel.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, viro@...iv.linux.org.uk,
 linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
 duanxiongchun@...edance.com, yinhongbo@...edance.com,
 dengliang.1214@...edance.com, xieyongji@...edance.com,
 chaiwen.cc@...edance.com, songmuchun@...edance.com, yuanzhu@...edance.com
Subject: Re: [RFC] optimize cost of inter-process communication

On 4/30/25 02:16, Jiadong Sun wrote:
> To attain the first objective, processes that use RPAL share the same
> virtual address space. So one process can access another's data directly
> via a data pointer. This means data can be transferred from one process
> to another with just one copy operation.

It's a neat idea and it is impressive that you got it running at all.

But it's a *HUGE* change in the process model and it's obviously not
generally applicable. You literally don't have small processes any more.
You only have big ones that are *VERY* expensive to tear down.

> RPAL is currently implemented on the Linux v5.15 kernel

Hmmm: "This branch is 196946 commits ahead of, 17734 commits behind
5.4.143-velinux."

So this isn't even on top of a stable kernel? It's 10,000 lines on top
of a ~200k commit fork? Yeah, I can see how it would take some
substantial effort to rebase it to mainline. It's also a _bit_ of a
stretch to call this a v5.15 kernel.

Basically, I don't doubt that this is good for _you_ and your
applications. But would anybody else ever use it? I seriously doubt it.
It's too big of a change in model and it has too many compromises in its
design. It's fundamentally not aligned with how the kernel evolves both
in ts design and its development process.

Unless something big changes (like a lot of users suddenly dying for
this functionality), this isn't even something I'd remotely consider
spending any time on looking at again. Sorry.