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 7CD54C5B543 for ; Fri, 30 May 2025 22:42:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EE3626B0147; Fri, 30 May 2025 18:42:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EBAE86B0148; Fri, 30 May 2025 18:42:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF78B6B0170; Fri, 30 May 2025 18:42:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C10EC6B0147 for ; Fri, 30 May 2025 18:42:55 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 4AC691A0404 for ; Fri, 30 May 2025 22:42:55 +0000 (UTC) X-FDA: 83501050710.24.AAE775C Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf24.hostedemail.com (Postfix) with ESMTP id 9D0D4180006 for ; Fri, 30 May 2025 22:42:53 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=cUql0G7M; dmarc=none; spf=pass (imf24.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1748644973; a=rsa-sha256; cv=none; b=WdiN/2mRTaqLZpvSjAKas7n8/CACanBcvoRzCSipygIKDKlXn5Au1YrExZPQv6Qoi+2NS7 ICWD+La0sFewd4De3AtKxTQNW87pK7KZCJD5D1CfEmNxweZwr3I7Fiw9VQCjvBLyjvLbrJ 1bbI4+4APrBBYlJoAP7RZNYafS4Mq8c= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=cUql0G7M; dmarc=none; spf=pass (imf24.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1748644973; 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=gHbx2/PagsVvWhJbtYFsFOjvRMJ+oYrPZLWo26t+kNU=; b=szHK0YTmjnKU1Da6RSy/SonY/jGe0RAqetGz9hGYUrQ6gx15WvMLUDBYb4/sgkXyAR/xKE INfNyD9O+ywQ4TK/d1Cn5XjHARF3DBNF+Oav3ljWPdlcQWunr7UBP0z9LKsEv3Xtk3qL05 c9XmowmX7DnMLkyPoom6Qc3vpMLyjdk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id ACFA460007; Fri, 30 May 2025 22:42:52 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A865BC4CEE9; Fri, 30 May 2025 22:42:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1748644972; bh=B/iHNMvw8mF0JmcbV/Ww2Zu1GyyER0SInWNMF1ybJBs=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=cUql0G7MM2YqNN/UBvnnZgBT5VGYfWKe1XBDEBCJVTML/dklTuCOChratyStM1z3r NJGXoD/xMliKV8+qGZt/n12lWHmh43UX9/OjWVD4xk4/ASqHI1bHx3hR+6ehcrgJ/t CSb9wxzn0ZeI/U2uCsz/KkL5wFRvOwr+0ymJ1WYM= Date: Fri, 30 May 2025 15:42:50 -0700 From: Andrew Morton To: Bo Li Cc: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, luto@kernel.org, kees@kernel.org, david@redhat.com, juri.lelli@redhat.com, vincent.guittot@linaro.org, peterz@infradead.org, dietmar.eggemann@arm.com, hpa@zytor.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 Subject: Re: [RFC v2 00/35] optimize cost of inter-process communication Message-Id: <20250530154250.15caab4e3991de779aabe02c@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 9D0D4180006 X-Stat-Signature: pi56qe6f949sf1rhwo7wkdsrcbhfxaxr X-Rspam-User: X-HE-Tag: 1748644973-741638 X-HE-Meta: U2FsdGVkX1//pEmVjXW+2iHGlU5bREpMb16FPMK02E1j7pT2omHqUJ3DEgpht22RgMUpFN0hkWP3fc5Dww6CBWgwx1NA8AKQt52anaM1OoyCWcZI0Xpk5eiFWfQhzb6VxPUrvyDbW78BLM1toidvOyIQL023++h5FWjA/IDQXoggyA19GKL+TYIzC2tRWBdRXTIFnztV/C2eZ23E8ZU+WYRKZ76MZ9C8rW+OjEf/TqRWG03ULYdKIe8qvrFxiOD7fUDMuzdDVkL0RPEAtaSC4C7tqSpoYtqZjFTZms7OOIu4LV7Qvs24M27jJ8ojQlrDvoQRI9oBDDLg95upd0dyQrbEdVqrmbM34PUYUWEoiHK7sAS/2gY9ymExokzrjlWNoH0IxUT7lEmsnKeXIHtc7nhsOTOztzjhGMv6QYWM9caWeBWBvK1dT1YPYevU4RTOxrVIoBvZfTY/p+LU7mqCZSiz4c3eg3TFCfxSxJ93ZS4snO3RvO86MxeuTDBT1sBwnRmqiRJZXjZ9t9dfgfJWp+SzDe47M8XDw6RHS13IdKeEz6xVUSwvZbUJJ2xHEcparTSu3FS41yjfwULVpZK0uP14Ze828aqT4LTraI1u2ezOvxZZqFiog0XVYxSzrlUH/WB1s1I1Pb1QViO6zLA+9YgXgoRpNF6XRSEZR1myY3qTaGJ8Dp5sDsexveMU5m21wQ4heIFsorZ8QMuI3ftvxkNjOR5I0VwV+CWbpUc2ijTHN5zwr4g3fGma0D8sNBvgSN52GqtpmY8/Utns+QZPu35fgPm29COrIStxqaYuAZ5Uy421cn5g+7dBX6fIMiLu+Fcacn4O/B9TXbNM9iXHy91wI06FIOB/W1smGIj2T99v/3GokslvhhFcb65OaEDtBek96NiGe9i1ujdVBzQ6WcheaZWSwHeYBbWRQC4LRGPH6TsX8awLHbjBiFaMyjlptukqfm1ctFvREP6E8Gm /0hSYXJ2 5oSkl9Fyksmb314CA7b6fBK/76eiQBOSkh1cXKhK38I82eE4fepFxjsNP39PxNdCD8aodra/bvr5y8IGGteYe7SaQOfUBmQ9nHk5Q98z3aieztp4xCtTyLLYIYr6zrcUVK+0OeJ9QmUclpdzBGxD4U+VkeYGUJrlPeD1fnalapGHihP4O8A6qYu1XnZFQvHwF7rkIqjL3FFeTnjVAIXoEvO10YxDt148bx5eMkLwHwSLqSAUhjZRG/AlfRDt/heLbfCxUGKUCkvbw0f4z0hNIhAI+UukrTcxJSudgRbFMr1wwPYE= 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 Fri, 30 May 2025 17:27:28 +0800 Bo Li wrote: > During testing, the client transmitted 1 million 32-byte messages, and we > computed the per-message average latency. The results are as follows: > > ***************** > Without RPAL: Message length: 32 bytes, Total TSC cycles: 19616222534, > Message count: 1000000, Average latency: 19616 cycles > With RPAL: Message length: 32 bytes, Total TSC cycles: 1703459326, > Message count: 1000000, Average latency: 1703 cycles > ***************** > > These results confirm that RPAL delivers substantial latency improvements > over the current epoll implementation—achieving a 17,913-cycle reduction > (an ~91.3% improvement) for 32-byte messages. Noted ;) Quick question: > arch/x86/Kbuild | 2 + > arch/x86/Kconfig | 2 + > arch/x86/entry/entry_64.S | 160 ++ > arch/x86/events/amd/core.c | 14 + > arch/x86/include/asm/pgtable.h | 25 + > arch/x86/include/asm/pgtable_types.h | 11 + > arch/x86/include/asm/tlbflush.h | 10 + > arch/x86/kernel/asm-offsets.c | 3 + > arch/x86/kernel/cpu/common.c | 8 +- > arch/x86/kernel/fpu/core.c | 8 +- > arch/x86/kernel/nmi.c | 20 + > arch/x86/kernel/process.c | 25 +- > arch/x86/kernel/process_64.c | 118 + > arch/x86/mm/fault.c | 271 ++ > arch/x86/mm/mmap.c | 10 + > arch/x86/mm/tlb.c | 172 ++ > arch/x86/rpal/Kconfig | 21 + > arch/x86/rpal/Makefile | 6 + > arch/x86/rpal/core.c | 477 ++++ > arch/x86/rpal/internal.h | 69 + > arch/x86/rpal/mm.c | 426 +++ > arch/x86/rpal/pku.c | 196 ++ > arch/x86/rpal/proc.c | 279 ++ > arch/x86/rpal/service.c | 776 ++++++ > arch/x86/rpal/thread.c | 313 +++ The changes are very x86-heavy. Is that a necessary thing? Would another architecture need to implement a similar amount to enable RPAL? IOW, how much of the above could be made arch-neutral?