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 516D7C3ABA9 for ; Wed, 30 Apr 2025 14:03:26 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 248166B00B5; Wed, 30 Apr 2025 10:03:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1D0D16B00B9; Wed, 30 Apr 2025 10:03:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 021B86B00BA; Wed, 30 Apr 2025 10:03:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D2FC06B00B5 for ; Wed, 30 Apr 2025 10:03:24 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id E546081C87 for ; Wed, 30 Apr 2025 14:03:24 +0000 (UTC) X-FDA: 83390877528.26.5222627 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.10]) by imf27.hostedemail.com (Postfix) with ESMTP id 8DF1940007 for ; Wed, 30 Apr 2025 14:03:21 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=UlsIjj1y; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf27.hostedemail.com: domain of dave.hansen@intel.com designates 198.175.65.10 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746021802; a=rsa-sha256; cv=none; b=51HWuKrc5JDLAvOrf1DxnnZ7g0y9lZlvWZ/vfsDQqL/F4ZYC9LHV+rbYgHV+3Qh3c5+5CS tFMPeUBR2bX/QGvaoXlLbukArRc5Vk/luXH131ac6n1+eVUfJruNyOqRtrsEAQ8AaxEFji rcb3cK3w2SnpX2QZ2inWsjMEvV9vu7M= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=UlsIjj1y; dmarc=pass (policy=none) header.from=intel.com; spf=pass (imf27.hostedemail.com: domain of dave.hansen@intel.com designates 198.175.65.10 as permitted sender) smtp.mailfrom=dave.hansen@intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746021802; 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=oV9B2r0VrTgigR4sUinXlFwe6m8WkIqU+og3Gf2XdH4=; b=PKczlGAqj3OVcIEbPI8Ks/Re5A1EgD28GmSid17zI4WxwsgRkYWYjDokV1ZEYfJnlSKSUV 0o+CBkh8UwlIFRbU+dSwDYcmdnCw0jkMfneEP761v6Z1vyQk66fSifZmcl0QCvJcYhue8f +7pPJ7k0FW/s/Q5Sx1BQypL2xZ0g0q0= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1746021801; x=1777557801; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=oV9B2r0VrTgigR4sUinXlFwe6m8WkIqU+og3Gf2XdH4=; b=UlsIjj1yUxskdbVmmI6Cy1ORn8KjJULOEPPiArr8mIkzo/i9emEBl4ND 9SBwW6PBLtr72lGg54dklC9AVEWE2DOguwFQpmovh4ukLM+rwjzwV+Pa+ ZMjtTcg32yeAx+prxQabSwcjMNDCbvhpE4ZUxhtK5jLlgOHYlVcacQKiT 33GMwLqHK7Tv+uCQJ/ZHOM2pghAX6svrQOvs1xIBl/D6gMkGXGRV+5o2O ZyDySua2TGo66urmGheKH73kqI8Y4lh/iXbwq0wwIK5Kwf+aL6CfssmjK OUv6UyM51TFpxXGi1B8Z55sf8GQHkFRJpbvQJAd4EQjCcH71rGHzEgeac w==; X-CSE-ConnectionGUID: bPTbqmaHTPiWSch15GpemA== X-CSE-MsgGUID: o2jhwxzMSx6+kqOQJoofzg== X-IronPort-AV: E=McAfee;i="6700,10204,11419"; a="65096250" X-IronPort-AV: E=Sophos;i="6.15,251,1739865600"; d="scan'208";a="65096250" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by orvoesa102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Apr 2025 07:03:19 -0700 X-CSE-ConnectionGUID: Z2iOPct0SmG484vb6sAtnQ== X-CSE-MsgGUID: bhME4bkBS+u+IQ6JP/GOyg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,251,1739865600"; d="scan'208";a="134656948" Received: from bkammerd-mobl.amr.corp.intel.com (HELO [10.124.223.145]) ([10.124.223.145]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Apr 2025 07:03:15 -0700 Message-ID: Date: Wed, 30 Apr 2025 07:03:12 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] optimize cost of inter-process communication To: Jiadong Sun , luto@kernel.org, juri.lelli@redhat.com, vincent.guittot@linaro.org, akpm@linux-foundation.org Cc: x86@kernel.org, tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, viro@zeniv.linux.org.uk, 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 References: From: Dave Hansen Content-Language: en-US Autocrypt: addr=dave.hansen@intel.com; keydata= xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzUVEYXZpZCBDaHJp c3RvcGhlciBIYW5zZW4gKEludGVsIFdvcmsgQWRkcmVzcykgPGRhdmUuaGFuc2VuQGludGVs LmNvbT7CwXgEEwECACIFAlQ+9J0CGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGg1 lTBwyZKwLZUP/0dnbhDc229u2u6WtK1s1cSd9WsflGXGagkR6liJ4um3XCfYWDHvIdkHYC1t MNcVHFBwmQkawxsYvgO8kXT3SaFZe4ISfB4K4CL2qp4JO+nJdlFUbZI7cz/Td9z8nHjMcWYF IQuTsWOLs/LBMTs+ANumibtw6UkiGVD3dfHJAOPNApjVr+M0P/lVmTeP8w0uVcd2syiaU5jB aht9CYATn+ytFGWZnBEEQFnqcibIaOrmoBLu2b3fKJEd8Jp7NHDSIdrvrMjYynmc6sZKUqH2 I1qOevaa8jUg7wlLJAWGfIqnu85kkqrVOkbNbk4TPub7VOqA6qG5GCNEIv6ZY7HLYd/vAkVY E8Plzq/NwLAuOWxvGrOl7OPuwVeR4hBDfcrNb990MFPpjGgACzAZyjdmYoMu8j3/MAEW4P0z F5+EYJAOZ+z212y1pchNNauehORXgjrNKsZwxwKpPY9qb84E3O9KYpwfATsqOoQ6tTgr+1BR CCwP712H+E9U5HJ0iibN/CDZFVPL1bRerHziuwuQuvE0qWg0+0SChFe9oq0KAwEkVs6ZDMB2 P16MieEEQ6StQRlvy2YBv80L1TMl3T90Bo1UUn6ARXEpcbFE0/aORH/jEXcRteb+vuik5UGY 5TsyLYdPur3TXm7XDBdmmyQVJjnJKYK9AQxj95KlXLVO38lczsFNBFRjzmoBEACyAxbvUEhd GDGNg0JhDdezyTdN8C9BFsdxyTLnSH31NRiyp1QtuxvcqGZjb2trDVuCbIzRrgMZLVgo3upr MIOx1CXEgmn23Zhh0EpdVHM8IKx9Z7V0r+rrpRWFE8/wQZngKYVi49PGoZj50ZEifEJ5qn/H Nsp2+Y+bTUjDdgWMATg9DiFMyv8fvoqgNsNyrrZTnSgoLzdxr89FGHZCoSoAK8gfgFHuO54B lI8QOfPDG9WDPJ66HCodjTlBEr/Cwq6GruxS5i2Y33YVqxvFvDa1tUtl+iJ2SWKS9kCai2DR 3BwVONJEYSDQaven/EHMlY1q8Vln3lGPsS11vSUK3QcNJjmrgYxH5KsVsf6PNRj9mp8Z1kIG qjRx08+nnyStWC0gZH6NrYyS9rpqH3j+hA2WcI7De51L4Rv9pFwzp161mvtc6eC/GxaiUGuH BNAVP0PY0fqvIC68p3rLIAW3f97uv4ce2RSQ7LbsPsimOeCo/5vgS6YQsj83E+AipPr09Caj 0hloj+hFoqiticNpmsxdWKoOsV0PftcQvBCCYuhKbZV9s5hjt9qn8CE86A5g5KqDf83Fxqm/ vXKgHNFHE5zgXGZnrmaf6resQzbvJHO0Fb0CcIohzrpPaL3YepcLDoCCgElGMGQjdCcSQ+Ci FCRl0Bvyj1YZUql+ZkptgGjikQARAQABwsFfBBgBAgAJBQJUY85qAhsMAAoJEGg1lTBwyZKw l4IQAIKHs/9po4spZDFyfDjunimEhVHqlUt7ggR1Hsl/tkvTSze8pI1P6dGp2XW6AnH1iayn yRcoyT0ZJ+Zmm4xAH1zqKjWplzqdb/dO28qk0bPso8+1oPO8oDhLm1+tY+cOvufXkBTm+whm +AyNTjaCRt6aSMnA/QHVGSJ8grrTJCoACVNhnXg/R0g90g8iV8Q+IBZyDkG0tBThaDdw1B2l asInUTeb9EiVfL/Zjdg5VWiF9LL7iS+9hTeVdR09vThQ/DhVbCNxVk+DtyBHsjOKifrVsYep WpRGBIAu3bK8eXtyvrw1igWTNs2wazJ71+0z2jMzbclKAyRHKU9JdN6Hkkgr2nPb561yjcB8 sIq1pFXKyO+nKy6SZYxOvHxCcjk2fkw6UmPU6/j/nQlj2lfOAgNVKuDLothIxzi8pndB8Jju KktE5HJqUUMXePkAYIxEQ0mMc8Po7tuXdejgPMwgP7x65xtfEqI0RuzbUioFltsp1jUaRwQZ MTsCeQDdjpgHsj+P2ZDeEKCbma4m6Ez/YWs4+zDm1X8uZDkZcfQlD9NldbKDJEXLIjYWo1PH hYepSffIWPyvBMBTW2W5FRjJ4vLRrJSUoEfJuPQ3vW9Y73foyo/qFoURHO48AinGPZ7PC7TF vUaNOTjKedrqHkaOcqB185ahG2had0xnFsDPlx5y In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 8DF1940007 X-Stat-Signature: 9q1sq9zwger9r9ejdi5uhpe9u15wd4cd X-HE-Tag: 1746021801-357639 X-HE-Meta: U2FsdGVkX1+0XdW6mionh7n6RAqU2R8KeSP/TdqdbXuABN8zYV9Bih45JXhpnul9gWgX3rAuIJG4YJKOl5MCouMZczHLKGRDLyZ64dQR/wkt8Nmf14I7IqsJlDA2VUV94rb5Ui50S1HXyCQdidCb9uHcK9+3Y7lbN88lDgUJsH2BdTwHzBA7Ty/1lyMglQrazaKhIOoEJp10XQzN3oFcC0yKF9Q+TVn2TW7d1lWk0HMtvBWByeNU47jl8DpP1EkSP/if5zFo3xQuXol3Dz0OXHBcCowzv+TAyJE7wdJkuxx1IObmCWioV/ALmZVJoOvv87bLwjauHRICEMuE6y1DhNNwPkNOKluVF8jljW/72HkOs4tTS9BuRWssAlMEYt3TtzZZ73nR/RF/eCjgJhHMn/RENxcd3SSszIafanuya45MZgnNDyBO/ZyS1mMegnvQ9VkUdo3NAIzCBwCvBsu3Er5E1E8tcoF9okRD78dR02qNXKMJXedukSJVHSQDP9PupRpzVoPUE10A+icUMRFXKiagFkAGt+T5DJndEciSOP7vldG/LfxxeTLPLyLXGBYL36ReF5tIj1CGWj9u/sYjtA9gGUUgc+9CbFD1Dbp8+oTOMwjzqhoRakJ1hPB8yKiCc9WQvK2t9Hpd0NDuL86vhPA1wJ4PB3XeTKzJu7LXzlwYJi8nzaZcAhn0c7vyHNLktReZkUaWZdd9luo3NtotVPL6LExutI2i6m0vr4NOmq5DQMckUIntiuHPj95HzUJuG+14VAon3Wlj9sn7jyVt3EHTWwbM0mlDz4l9/2M7/K2M9YJKHI8eRX+GCs8MZtHr3Pmdla+2l6LnSXLPnTTB+pFyK+oJa+nS3Q8xeBwaudtZeO3VGIm3eHK/EeCl/vEY 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 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.