From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E140BC5AD49 for ; Tue, 3 Jun 2025 17:50:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79D896B04DA; Tue, 3 Jun 2025 13:50:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 74E746B04DC; Tue, 3 Jun 2025 13:50:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 63CD96B04DD; Tue, 3 Jun 2025 13:50:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 433146B04DA for ; Tue, 3 Jun 2025 13:50:35 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id E5C06C12B0 for ; Tue, 3 Jun 2025 17:50:34 +0000 (UTC) X-FDA: 83514829188.12.8D2AA5E Received: from mail.zytor.com (terminus.zytor.com [198.137.202.136]) by imf12.hostedemail.com (Postfix) with ESMTP id CA5314000E for ; Tue, 3 Jun 2025 17:50:32 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025052101 header.b=X0ud+K1O; spf=pass (imf12.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com; dmarc=pass (policy=none) header.from=zytor.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748973033; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=WjcKG8tapzY+DwZpr1CTpwzaMFTYG50aHolFcfHdfs4=; b=iNi7NbAve9IQ5ybeLjIM+bBnEHs3vC0q6voV6/i/TAZL4j0gvL1/TdAfhR9bxVpn62FVlX JQM2lq+aGbh4Cp69hUtMkBJflYZgRZkkuND2OusU+eJPMSeq6bb5dyrQPPoz1mipjne0ri oL/gboy2TVpLyTY5FQayA7DsiWyS4uU= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=zytor.com header.s=2025052101 header.b=X0ud+K1O; spf=pass (imf12.hostedemail.com: domain of hpa@zytor.com designates 198.137.202.136 as permitted sender) smtp.mailfrom=hpa@zytor.com; dmarc=pass (policy=none) header.from=zytor.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748973033; a=rsa-sha256; cv=none; b=5dAl3+I+BL3REnfDnQShJit0lk5yuFYbJ2e3HaInQFKNispoqU40RSk04DiFdtyOLPFxBW sQYitPHizTVaJFSwNMpEsrKzLoS2xtZrTbTAFd23hrrXvWHU1y2O3X8lhoDviJ+s8w3tj1 X35E1vfGQN4sNb+yKPaQYWUg/7Tq1so= Received: from [IPV6:2601:646:8081:9482:7211:64cb:5036:d2b9] ([IPv6:2601:646:8081:9482:7211:64cb:5036:d2b9]) (authenticated bits=0) by mail.zytor.com (8.18.1/8.17.1) with ESMTPSA id 553Hne8u3926666 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 3 Jun 2025 10:49:41 -0700 DKIM-Filter: OpenDKIM Filter v2.11.0 mail.zytor.com 553Hne8u3926666 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zytor.com; s=2025052101; t=1748972985; bh=WjcKG8tapzY+DwZpr1CTpwzaMFTYG50aHolFcfHdfs4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=X0ud+K1ObXeIOmkFYd4oZPi19mpm7QhPbViuLKFsUdAnzO94VI+3AnlPSbZSzijQ8 WPu1ufL6nvVHW04XF/MECy3aNKi3jUpR7gB3qLvkIAsXFjT3uJB9nj8bCMwgirEiTv +siS7X5E4aWy3AvIjRgGHvnJdLXTnNTzRUku1MJMx7dwPGQNfOv0GQDGD6NMP23knP PBfWAvUzbpsj+VnpW3bwW4CwOter3tKgFuoXD9kQ8q1FiHLU9CXsjMSwLRGdYFCyLB IBs3jDqdc3fSs4hgdxuQ93k0Sl/119q0UB7t4c36TPeDCm6b4p5tM9+XKqRyIqD23t riIZ13jyEUqHw== Message-ID: <380a64b9-e796-4345-a9a0-cf70d0f6c26f@zytor.com> Date: Tue, 3 Jun 2025 10:49:35 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC v2 00/35] optimize cost of inter-process communication To: Bo Li , tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, luto@kernel.org, kees@kernel.org, akpm@linux-foundation.org, david@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, peterz@infradead.org Cc: dietmar.eggemann@arm.com, acme@kernel.org, namhyung@kernel.org, mark.rutland@arm.com, alexander.shishkin@linux.intel.com, jolsa@kernel.org, irogers@google.com, adrian.hunter@intel.com, kan.liang@linux.intel.com, viro@zeniv.linux.org.uk, brauner@kernel.org, jack@suse.cz, lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com, vbabka@suse.cz, rppt@kernel.org, surenb@google.com, mhocko@suse.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, vschneid@redhat.com, jannh@google.com, pfalcato@suse.de, riel@surriel.com, harry.yoo@oracle.com, linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, duanxiongchun@bytedance.com, yinhongbo@bytedance.com, dengliang.1214@bytedance.com, xieyongji@bytedance.com, chaiwen.cc@bytedance.com, songmuchun@bytedance.com, yuanzhu@bytedance.com, chengguozhu@bytedance.com, sunjiadong.lff@bytedance.com References: Content-Language: en-US From: "H. Peter Anvin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: CA5314000E X-Stat-Signature: d4ygk7zk1u3wddm4air3fk398trit4nh X-Rspam-User: X-Rspamd-Server: rspam04 X-HE-Tag: 1748973032-536545 X-HE-Meta: U2FsdGVkX1/cGmSp2DwcYQCIRT4mc4jYVnuor7AB06UNCwcLWwQnmvkZjjuGCx16vi+9NZLg3expMaGRa6GECf2DuPiMpf3l9At0RCECqHsByAz/h8WLiH4sK/aEiajnwcBCut7dkenIDvRFQjt2KjQ8o3+OwAR3aspa+rGkmtAG/r2AxHFYYXIYxMiqzztYK+zGTn4uXLuYTVaEbOfxViDF0M8/QK+uyw9ZYjBVjlr2Pke2H7RB3zEnrB2u3w6wm5OxcJx94ZBnQ/M+zR1unDq3aue5TCaTiR3NsKEExij3euU93XcZi+3wlRfiY+SN7xNNk41ucthcYn4qaaFFe9qfxLWae6eWitZeQQeAJvyUlz+iMZa5Haurqb/xodn18kKGM1LXSN7zeDy8RGvhLyROi4FzwzcC9M6tAHi/dNOjQ6wSA6DKdifinf9eARv4h9ntyGP0GDb6HR9uV22+zGVtSr5CFlpYByffP8zNSUWiw7O4viroJTtXr1uDkKzaI2DIW3Kun5f7wooT27rH2vPoQOc7TAW7Seu+vudWAVqBg65f47Fu4enntuS3pv0AO/rEgbYG95xMyECYdN2ONrEJl1yIFExrpQMb4NgP51W2zbei6B8DSGJwvSmNSkRCUgeKmfLnC8ysvtvBu3xv7f0MyxNlMU/sAxAV7QbvAM2q8Sv5nd1uo1T2JyER3YTbG/HN8jpsL2A+GtvY6FVl2hUcb9GKHDBhKVv7r6zz5lVuOBz7dyC/1Rr13N9NOIEPgY9bt/QIGZD8Cm/i6cyfi9GUK0qKij+ucvGW61hRDQagguiloBqfQeEFp+4YrwHLoFaLcuSzQTnET0VSlfa4L56hSnwjxpEoUzbxdcCo5CysPvxS5JWa7jE0sbWe8hHcPO7aH1zWRFytnnbBRPWXFkAw47sBPzZ8Inh/a3p2UuQDGDiG/nhFJ0PXAFN+EZuYBCixhsI5iAc= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 5/30/25 02:27, Bo Li wrote: > Changelog: > > v2: > - Port the RPAL functions to the latest v6.15 kernel. > - Add a supplementary introduction to the application scenarios and > security considerations of RPAL. > > link to v1: > https://lore.kernel.org/lkml/CAP2HCOmAkRVTci0ObtyW=3v6GFOrt9zCn2NwLUbZ+Di49xkBiw@mail.gmail.com/ > Okay, First of all, I agree with most of the other reviewers that this is insane. Second of all, calling this "optimize cost of inter-process communication" is *extremely* misleading, to the point that one could worry about it being malicious. What you are doing is attempting to provide isolation between threads running in the same memory space. *By definition* those are not processes. Secondly, doing function calls from one thread to another in the same memory space isn't really IPC at all, as the scheduler is not involved. Third, this is something that should be possible to do entirely in user space (mostly in a modified libc). Most of the facilities that you seem to implement already have equivalents (/dev/shm, ET_DYN, ld.so, ...) This isn't a new idea; this is where the microkernel people eventually ended up when they tried to get performant. It didn't work well for the same reason -- without involving the kernel (or dedicated hardware facilities; x86 segments and MPK are *not* designed for this), the isolation *can't* be enforced. You can, of course, have a kernel interface to switch the address space around -- and you have just (re)invented processes. >From what I can see, a saner version of this would probably be something like a sched_yield_to(X) system call, basically a request to the scheduler "if possible, give the rest of my time slice to process/thread , as if I had been continuing to run." The rest of the communication can be done with shared memory. The other option is that if you actually are OK with your workloads living in the same privilege domain to simply use threads. If this somehow isn't what you're doing, and I (and others) have somehow misread the intentions entirely, we will need a whole lot of additional explanations. -hpa -hpa