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 0093DC04FF6 for ; Fri, 19 Apr 2024 15:55:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 610DE6B0099; Fri, 19 Apr 2024 11:55:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 571D96B009B; Fri, 19 Apr 2024 11:55:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3EB2A6B009C; Fri, 19 Apr 2024 11:55:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1E8066B0099 for ; Fri, 19 Apr 2024 11:55:20 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D4E7E4033A for ; Fri, 19 Apr 2024 15:55:19 +0000 (UTC) X-FDA: 82026730758.26.C60BBA9 Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf21.hostedemail.com (Postfix) with ESMTP id 4437B1C0018 for ; Fri, 19 Apr 2024 15:55:16 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FtraKzw+; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of song@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=song@kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713542118; 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=vBdNZOjgGF682yjGGjFJtNq48VRV49l+U/QcLh2r/tA=; b=6hya2KnS/CFecegoDMXRP1o4DqN0T1QcfNutIeJAVsNZUGHVINMFXClDmVDOf6Ayr1A4Zt 1XzZYrwXoOd3Y2po7/lRPdyXZ/LuZsItPrav0Cle1je1cwIKCWSNSjMMoTxrCeVZxpcYZi E3Q0tGrxajWcmqYxoD+841kBKtPijCw= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=FtraKzw+; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf21.hostedemail.com: domain of song@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=song@kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713542118; a=rsa-sha256; cv=none; b=oVd6V8bjhi6fIfEtJY9PfZPpCjCt8pTdAj8q+u0n2o0ubUB2DNqnTpEBjzkuP9IrnWxWyh /XnoDm2LcrWofg7m7puezdcoGJwEU+HsGVmY8GSleDilt5/ixLRDBdy7sFsFvvuvzb1td+ 57Cu9sni7nt/qKNOeaiIRZxLkqEcXkA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 5E4CCCE1AF4 for ; Fri, 19 Apr 2024 15:55:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8FF16C072AA for ; Fri, 19 Apr 2024 15:55:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713542113; bh=PNzXHy/tRctT7iPO4Hxb0l/pQDROtMOUfttALn8mdWw=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=FtraKzw+sfNvSwvt7VfUmUbBIs7zGKo3oByYr5HzopXE5fTBP4S6axkbwuNsWFicb LmGAFKW4qtx5PQUQE0266uCTSuANNWrva/aqRvKOkn4znMQ/6qDG72Zh8x5QBq6S97 QLn96tTZnVOKVukmgIbfYzXTJsj2JHKbKSJV2twtQ6nfQDA2wcMMGGSQnVnLgdiGHG AKAK/UjckyJvbee7VTGYvdzAlV0ikWp24NjR8phfwLMCMYJSKGR83JY7PLnKxViGZ4 0FLrovCeRxXStaA+aEPr0Qh/zOho6Q7UC/C/B4P4nt4X/AmopaDrY4ZcPklqjvrS+8 LUOqtqt0IAjGA== Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-a5224dfa9adso386572266b.0 for ; Fri, 19 Apr 2024 08:55:13 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCWQqRjgjFP9B2O74eqVbE7GcWM4PxZnSkiG/uvOhzRweJp7fLz7DvH0lTHKZfraQVnPhbjAcpy8pI3f1DkQMOPyqjU= X-Gm-Message-State: AOJu0YxNHsh+aGIDOECjMWgxUSlUtJ/3O7oZFUEWPRxXSIT9/yHN/ZyK lmX2rcUbSGo++19CuFjrIf5sHC4O6tX5laY2mg+l6QP2cGZixHNlT9UbhDGCLW5VlycXgDDPvYx DSjpzkbKRfLdGXTGqlF8Pav5wXb4= X-Google-Smtp-Source: AGHT+IGasMltj1XTiWxWNEYkPSMxwP63y2jyTt8tLpdHn26unpYTPPkYdRp/dT6gEwD6NrNiKXUtIlL7PF9cDNubUq4= X-Received: by 2002:ac2:5f9b:0:b0:519:ab33:7459 with SMTP id r27-20020ac25f9b000000b00519ab337459mr752898lfe.30.1713542091952; Fri, 19 Apr 2024 08:54:51 -0700 (PDT) MIME-Version: 1.0 References: <20240411160051.2093261-1-rppt@kernel.org> <20240411160051.2093261-6-rppt@kernel.org> <20240415075241.GF40213@noisy.programming.kicks-ass.net> In-Reply-To: From: Song Liu Date: Fri, 19 Apr 2024 08:54:40 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 05/15] mm: introduce execmem_alloc() and execmem_free() To: Mike Rapoport 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 4437B1C0018 X-Stat-Signature: ap14rpwews7885hnsetz1asfk4rz46dp X-HE-Tag: 1713542116-584546 X-HE-Meta: U2FsdGVkX1+HiPwYx1Gp7rQL5B02eDDpKm2os1XndMgcdBkaU3L7LlLlMMGuqKM2ywPGs+5lJb0OzGxQK4D9j5pxM/yBtk1XwK9E5Tg5ibDaHaGHh1pa9AW9JRS+DPpkR4eAW1Fq61iULd18aukPnWsLslFQsCdeRZ1cMC9aroBBEBuDYQcui81P3n7uTo8y3U4sK6YLC9/Rpz3wajxQog/W1c37MKjbYHz8/tCMNZCZDIkhGTHnIGvc8aoIjexj9fueGTJ/NDbBYfZEGS+SjFozCw88hvbIb9DaNv2qsAiQp1ziKJ6SVCVGzU2Zw6ZSd0bO5NLrLXzIovvNGX981lY1Th7DF9Wc3tiKFyoZbEPYM+8p+pkDlqVV65xFLxOrHr84c32koKsfHkKjkHJU7CpIzg8TMSKni5DgYqF+dOtBnVfv9sIh8ohLzBhlKcP7h3tGNPQtusc2tTGUIIjc8n/XCm7ug+wg35lB84lt+/kWYGHL4pnUdRR1ZTBFeruaF/tLHd7WOJU+mmh2G1AhDoURr9ck763ZCUKTjx1Xv+xy/zNiBW/w4HPDZrejjpQQAse8JzNoA72BGe+YNRACE36a4ax3mXb+nEKYCauvvQRpB0LSE/5/UqmEr2mgYOOZQ1wrkMK25G/2mosNLb6koRzDLWk2+CxpSnFU5Yt93OZq7QZtRZicr8AMkaVrH2Y7YVHLs4WuYUJtIXtG53iW7n3l/Y5QRTY7RJaUkk5zakPbsAJSksxlGD9fl0tuqfFUsSqB+cPFGL4fYjyMk3BMj86kJbmjE5Kz4VcaMiaC6AzBaj1sP9HgwL6WfSvmCi8HHXaIGElo4O/XzNAHEQ8dqBTDWr9PRU5pNrmBshMiW5DCCKc/VcYI+TnOblwvp2l6/kdMDVEpMJdq7PCbyggY4QALOSLaj43NaWEnWaKVxcoYK7CuHynIPFVHbMukCbb9J5rPbzavxtL1/S4AejF DmHJ24CI hnbQ/YV+zWK8ztYTkMWxRNnltnN82UxEjTeDuvhR3TpIQgmyed65vInGzMo8QMP8Vs4P1PL9LFX88oz1khbQPgkEaDcIVC0f9yCXIke0YxQ1eMSJ2rhPDoBnlxn6oEUYPFYMUhVl/6JM0e2QkciNR7vGWH/+cZyNxiL4mBMeKa5qUVvmv3AOhj9MUQiolIH8DquYOoqN+ozRrzuRipCqEW7xWXCehdBp1lr4SxFRg6mtetrsRoqY3OS/eYWTX5yEZg1FpcKBTYWBqA5ClH2Oo5/Ac/ZMcJLqQyzHlJkRet7NGLRpzxFZlZq8nNPdpp9UVrCIXiX9spGXUsaLnwaih5FIuSwI6ARPHk3EEEg9oVSrSZyNEMkjiDdMVrAcpaQLTVszPcyNfiHjD+GE= 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 11:56=E2=80=AFPM Mike Rapoport wr= ote: > > On Thu, Apr 18, 2024 at 02:01:22PM -0700, Song Liu wrote: > > On Thu, Apr 18, 2024 at 10:54=E2=80=AFAM Mike Rapoport wrote: > > > > > > On Thu, Apr 18, 2024 at 09:13:27AM -0700, Song Liu wrote: > > > > On Thu, Apr 18, 2024 at 8:37=E2=80=AFAM Mike Rapoport wrote: > > > > > > > > > > > > > > I'm looking at execmem_types more as definition of the consum= ers, maybe I > > > > > > > should have named the enum execmem_consumer at the first plac= e. > > > > > > > > > > > > I think looking at execmem_type from consumers' point of view a= dds > > > > > > unnecessary complexity. IIUC, for most (if not all) archs, ftra= ce, kprobe, > > > > > > and bpf (and maybe also module text) all have the same requirem= ents. > > > > > > Did I miss something? > > > > > > > > > > It's enough to have one architecture with different constrains fo= r kprobes > > > > > and bpf to warrant a type for each. > > > > > > > > AFAICT, some of these constraints can be changed without too much w= ork. > > > > > > But why? > > > I honestly don't understand what are you trying to optimize here. A f= ew > > > 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, an= d > > 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 work= s. > > 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 cac= he 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 For the ROX to work, we need different users (module text, kprobe, etc.) to= have the same execmem_range. From [1]: static void *execmem_cache_alloc(struct execmem_range *range, size_t size) { ... p =3D __execmem_cache_alloc(size); if (p) return p; err =3D execmem_cache_populate(range, size); ... } We are calling __execmem_cache_alloc() without range. For this to work, we can only call execmem_cache_alloc() with one execmem_range. Did I miss something? Thanks, Song