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 EE65BC4345F for ; Fri, 19 Apr 2024 06:56:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 55B9B6B007B; Fri, 19 Apr 2024 02:56:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 50B7F6B0082; Fri, 19 Apr 2024 02:56:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3F9C16B0083; Fri, 19 Apr 2024 02:56:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 223656B007B for ; Fri, 19 Apr 2024 02:56:41 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9067AC037F for ; Fri, 19 Apr 2024 06:56:40 +0000 (UTC) X-FDA: 82025373360.06.3FE7E35 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id DF73A1C0002 for ; Fri, 19 Apr 2024 06:56:38 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GGPxC8PC; spf=pass (imf18.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713509799; a=rsa-sha256; cv=none; b=v7ydIACL6JTqxyVKSV3xfczNSZP4UMJ4W/Pnqj9vj6xWSGAO4eDcJ7z45NQG0/4IUJmb3F OQ9qr6QOIEE8Ijs7A1KmG/79YS0KNOJSPncwO16R9MTNEH6VrviGyGiE/FtrbzM/UrgTDX DepXIlyV5tc10PVWC3pm27zHcDetFvw= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=GGPxC8PC; spf=pass (imf18.hostedemail.com: domain of rppt@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713509799; 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=Po+ZjThlJ58KlI9Ax6xLkOdflFpfoLaa4+oHmFU/akw=; b=2fdVnlp/joj4sIIr5qmxosJVo73whykIgY4Zo+LQ92gljvyA87PyhuNfuxedxnFXZKAydD KQmaQBSaqOrzrcQ2UFmzxSA8YnYy6IcowUdl8Mu0JZfxrTkjbXrKtUVG38Xl0Agpxr+k8g h4Cc3wsbRmhdmjQeppBHmN+/3sxj60M= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 9E2956034B; Fri, 19 Apr 2024 06:56:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A5881C072AA; Fri, 19 Apr 2024 06:56:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713509797; bh=QyMnC6yNCYeGf0vrwo+bvOEGlhU1enTkpEMS1UdTz3o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=GGPxC8PCY8SnZrF0RCOMbIgSLrKy8hMUcTwQhGg04AArCCIqcrHmv5Ozj+/15Mxmb Z5tAH7Vdwb4CwNtAt3c/UrCpMIZJPngEV7ak2csa/7FlHToGNqqaiOtjXXYFiXJWt3 6ObsP+646nnF8SnH5skC5WEdWELGtHSHzBDWXZqXYwBofamn2QdDvdgy5CTKGNpPOO 1v84dtOt7AKF4KxvZWU3TOdBN2g9tkVxrJyakFg/qwL0NKQfGsXLfFOWV0O05jtLTZ wM29U64qOuZV772RLQ5j7ljjoO+qx0/azdfHFMH7xioH9AhimXQ/fqnfmBiI3Sy0+P 8Za6g/P3pUaVg== Date: Fri, 19 Apr 2024 09:55:16 +0300 From: Mike Rapoport To: Song Liu Cc: Mark Rutland , Peter Zijlstra , linux-kernel@vger.kernel.org, Alexandre Ghiti , Andrew Morton , Bjorn Topel , Catalin Marinas , Christophe Leroy , "David S. Miller" , Dinh Nguyen , Donald Dutile , Eric Chanudet , Heiko Carstens , Helge Deller , Huacai Chen , Kent Overstreet , Luis Chamberlain , Michael Ellerman , Nadav Amit , Palmer Dabbelt , Puranjay Mohan , Rick Edgecombe , Russell King , Steven Rostedt , Thomas Bogendoerfer , Thomas Gleixner , Will Deacon , bpf@vger.kernel.org, linux-arch@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, linux-parisc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-trace-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev, netdev@vger.kernel.org, sparclinux@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH v4 05/15] mm: introduce execmem_alloc() and execmem_free() Message-ID: References: <20240411160051.2093261-1-rppt@kernel.org> <20240411160051.2093261-6-rppt@kernel.org> <20240415075241.GF40213@noisy.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: DF73A1C0002 X-Stat-Signature: 8pjupbib4wxbfoxffy5e69f7jincn8ch X-Rspam-User: X-HE-Tag: 1713509798-533421 X-HE-Meta: U2FsdGVkX19E6XVZ5VzbWhQaa+QHiP/1C3suuvEJnA/9w+ZvTqmbLkrrZey+bqV4PUkfFio/x8y244QGNFYLcH1m6V27OKpVlfatnqatSyigDKlXrpgW35mGvgC2j8bMM284dhKvZAh8Wr4mc1UIyM57gupLHPUBgDQKQZuYKK6GhlkQfZkB5ROquyjvlLsJ6uJu9vPGjEhIRR7wL9ms73Vhg0ONYB3XUi/XlY1x0uakGT5FyGS/NlQh0bigaRTqzny1ZcMKNCtrbIOauP6GAXdl6k/FLUEb3dCotfm+CcODkGIuXTTSnhPlTRRS30n0h/O8qyFthahW9/14LqlK5Oy2MMy378a5/eIL6CzEzy489B6f6MtahrMB9EfXKhpV5Ui09HwyQ9IhSbqnpK2DfVEYZpnkY/yilILd1WhLVN3EgyXXf8vuYDXb+NJljP42FF+B8m/fAyEEC24MxqVLDN62/FCHT7kmU9B2p2SBb3NvRg12/7acy82/rhCnLSvgFzAut3sZKlv3+9rSeKSqxCpjLJLjA9OF9T86wSRKAb3GUKl37gDQfFDFuZ0nc5avvKkQNy05i02FYl8887v0Wf0jOnwNxgWAZq9T1bDEVNoGhGo2qiU+5E33JSs7HcgcuWeqH7djyJY/3lq0U/RiSo9K+biRgBzjWCr6z5CbdNOd6aAOMiCnTUPpgFIR+s3j53PoCzsJ2QbQ3XBfrbmBFKuy9pezgOk8Xf5GQzXeLiir5MmQVG4YrUhZ9UWqXOSd+znjqc5HURT4frRp9IPVSj3dvtVs+cVn78atNczStP9UiflC/B15W0hasRmEUBwvDc3Q2SOW23XXO7hX8aQg63bVbHZRKIWRPcEfDo8hB7yI3aQ/9KMrchTKT9ToH00nweWctdNjRH833a9kq6sR/A9Fr0YOHvYJTFHJw46fYhIYNg9xy+vjANb9ya8KwsEJs6VbSHpfIkK0WkUbnTz ODKy6ZVS RTtbrLz8hEwyJ1qwF0WFy5Jwm2MY+n/rXwrjivEI+uYnYcBG67VF0lSPTpt6ynq0mpFrOQkSiG2lurdy+C8kx/k2zvcLNKYcJbhFg72QcWkmcPeY8K7p2vXU9MCyDUzWLUVZlOQ9kjKSQPPVx/v/YCZwZPklhe+9xO6z1GKOqOTA7LPe8yCerzKpPrrwzsmY8QgHacj41YzkIVJn/0JkZ3KdPHky0bHucBAN2s+UoLdV97HsREv2lEMuMzZ8SbtHhtE8cksnXgKpjvJBgvjSTGX++chGivIcrWWjCJwpBo4jZxawcabTkxLwc7jvtdKnfeDO0KYHqDvurD41G0lUhpkUoIyY7Pv1IkW6W8cWgKdVcD+Tl7QamfE/YG5cdG3Spyt1KvG0An4d3Tkk= 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 Thu, Apr 18, 2024 at 02:01:22PM -0700, Song Liu wrote: > On Thu, Apr 18, 2024 at 10:54 AM Mike Rapoport wrote: > > > > On Thu, Apr 18, 2024 at 09:13:27AM -0700, Song Liu wrote: > > > On Thu, Apr 18, 2024 at 8:37 AM Mike Rapoport wrote: > > > > > > > > > > > > I'm looking at execmem_types more as definition of the consumers, maybe I > > > > > > should have named the enum execmem_consumer at the first place. > > > > > > > > > > I think looking at execmem_type from consumers' point of view adds > > > > > unnecessary complexity. IIUC, for most (if not all) archs, ftrace, kprobe, > > > > > and bpf (and maybe also module text) all have the same requirements. > > > > > Did I miss something? > > > > > > > > It's enough to have one architecture with different constrains for kprobes > > > > and bpf to warrant a type for each. > > > > > > AFAICT, some of these constraints can be changed without too much work. > > > > But why? > > I honestly don't understand what are you trying to optimize here. A few > > lines of initialization in execmem_info? > > IIUC, having separate EXECMEM_BPF and EXECMEM_KPROBE makes it > harder for bpf and kprobe to share the same ROX page. In many use cases, > a 2MiB page (assuming x86_64) is enough for all BPF, kprobe, ftrace, and > module text. It is not efficient if we have to allocate separate pages for each > of these use cases. If this is not a problem, the current approach works. The caching of large ROX pages does not need to be per type. In the POC I've posted for caching of large ROX pages on x86 [1], the cache is global and to make kprobes and bpf use it it's enough to set a flag in execmem_info. [1] https://lore.kernel.org/all/20240411160526.2093408-1-rppt@kernel.org > Thanks, > Song -- Sincerely yours, Mike.