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 C254DC04FF8 for ; Thu, 18 Apr 2024 21:02:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3A9F76B00A6; Thu, 18 Apr 2024 17:02:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 35A416B00A9; Thu, 18 Apr 2024 17:02:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2225F6B00AA; Thu, 18 Apr 2024 17:02:01 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 02A656B00A6 for ; Thu, 18 Apr 2024 17:02:00 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 7B223A147D for ; Thu, 18 Apr 2024 21:02:00 +0000 (UTC) X-FDA: 82023874800.18.A705229 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf17.hostedemail.com (Postfix) with ESMTP id 85CA440022 for ; Thu, 18 Apr 2024 21:01:58 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Dmze1zaX; spf=pass (imf17.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@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=1713474118; 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=Q9xFEu3Y5LoeO0EqCkhUGHL0dsvPtZI4/AmKYvf5MnY=; b=XhKkTspYpOcZmszRlTu7vgPbYxm1CjFAb32rRlxCHbVDqGnp6yXffBcrgQgQJ2Nj3ggGrT 5DhnEjBaEBtm3aKP76fNx6/zX7l4cREm37VWBV4ZfM6o0xVxOvNYLjIa6S8P5ZDXVv0NAm /NJc8mPJO0MdM8JGMsmuNB5D6rN55Ps= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713474118; a=rsa-sha256; cv=none; b=lNF/LwNOnntjSo3esNB6BiC7gSOzKdukbXgl+eAQEc1O+D9LErX05ZDtadV7K4JlGoHSVc +GFlyQB6HgGe+FDHuNsCBC8DBJETbTqy18zVdS1qkR6MtB3jAWtXlBAGdK6+QsJqRJXIcc NAkTBBC2jaxEeSdgOpG+KWtHLaL3ZGw= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Dmze1zaX; spf=pass (imf17.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 50B72618F3 for ; Thu, 18 Apr 2024 21:01:57 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0CC37C116B1 for ; Thu, 18 Apr 2024 21:01:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1713474117; bh=Q9xFEu3Y5LoeO0EqCkhUGHL0dsvPtZI4/AmKYvf5MnY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=Dmze1zaXKfE+0a7U9WFnGYtpYS290BCYEH0qEUdVzQ+Ke+zbWQlRPetdX1ReISvZs vLRbeW/lPUlT1WGaE8Cv3iptQRNSNadBOz/VGGnW1VdWPRcVLfG0/HuOGxcNDG7J00 OQoOGjxZSHEDKzPqTTkHwqdFG02IHoSa19nJnJP2npq8a4EWWL6JltPz7QTD+PFSEh yVgWE2HjK5bobAKqfsdJZrsRpsVeDpH0XrviWdgxrrSgMdsBBh6Ix11kukDSqtKid8 C0WWO/EdsZsPIEnSGB7vTdKTnyo2oUCz+571cPm7+mR2Xc3MdmcREuDbkd93ZwYs4o nTaLhEvf6fYDA== Received: by mail-lf1-f43.google.com with SMTP id 2adb3069b0e04-516f2e0edb7so1747578e87.1 for ; Thu, 18 Apr 2024 14:01:56 -0700 (PDT) X-Forwarded-Encrypted: i=1; AJvYcCU/k7VBnghn5enhXu/bDBr2HU5FmtTmQDUGJfPbg/ejb8GcG/bmw3V69ecLOzaqTjBnv3okJO22FRo2SfS5KXpNlIw= X-Gm-Message-State: AOJu0Ywo/511nRV5PxGTl3uCxFMgLxZR1az4DSNGBHdV/sV/HCgzv+YH 6p6BCaUYAQ+qWFJVfNBqWEOOUD0t5Ay+2IC4hxSj+mqFCbD/OXbTmrpSxz3vZOmPTGct1ga+q1Q DPkai6vybCpDzd77LaXPWIvneWFs= X-Google-Smtp-Source: AGHT+IHNxy9sJsnZs3KQVfU0+czeg8tBpsYhbjwNsSaDNt4tlgSyRo9Mz2ssjEN7kjA5vVRJEg5DihQkgyMA2Jl/jC4= X-Received: by 2002:a05:6512:1251:b0:516:cec0:1fc0 with SMTP id fb17-20020a056512125100b00516cec01fc0mr104453lfb.63.1713474094462; Thu, 18 Apr 2024 14:01:34 -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: Thu, 18 Apr 2024 14:01:22 -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-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: 85CA440022 X-Stat-Signature: mp95ha64nxr3xziewgy5ak6dkd78g6de X-Rspam-User: X-HE-Tag: 1713474118-909777 X-HE-Meta: U2FsdGVkX183MQhVoe5Om0moQdyfTCEwTcxq3cSooU8x1dcnBe4v3p2tfEGPpZoylPx7D7bMpVez/YadkirYEVPrgzRezTj7BqkC0xKGy0qUS3K0EAiVqr/GJgwhKu9XR1sPlQ5UqTx1E25x7O+GrLV/eWKP2q3H7JWzzjj/7PIHv7tkX+u7rnyj2jUF7mv6K8ZRL+9sIjCYH0KuzaK6zFa48hb5Ot9oWXAe38v4CYEtsN16mvX68w1UcS/ZhVmsW6sPZR1m6X1hWaOzPE3/0M58qI39k7d4+0LF8uyDAYxqZYxacf39o6ZUuFKrEEGVcDfp5BaGKHfaUnxFV82hpswlKEHZdNaj6YAd/5CKew2L4h7Cm+jtngiTpKBpNd9SKVFhZRIozioEeS9ckfYJUZvNdAmwt6cacF9Rwqg3z/lRIfGKCfv8KQ7Z7WB6ssebWd/ZiG9nnvgQyC+twCJsR56wQEk9sk8Pk+3Ss/rUTGpXyXHXyHYXNSLHKNiAKetQiheKrGZ8/DExi1l26EacAQ4slI/z2UMk5oQAgS08RECImes+tUumRYimxXe7ZX45zNsy4X8xAxsHlyHwKPUKwZnSk1jtP6mMlwcEtpGruYBx20Oq85WH/UghQq7u6f1iybQWd3yhTRym/+Ss9xNaO50f8cjjYzCRXO+9vpkyUX6UqjK1fxcvafKlsLRVclaF9xszrGoHfrHlp2QaULrQjA+VIai4iKPSXuXy4ixIcwlBLV4sxKpBa1WQLHky81Z3RkubzPgz0OrAaG0m9VkQCfpXfAFGaQi9azunddk0NS0t+78dy4JQdzvCYc5lZYU5tO1Mc349ziItcJe7ICztYAg4h4UwMjrkpPmHD/BG7YS0v49mOKFCnmRdm4ne/6hUojZRRLv5yAG48fZ3qYryQY0RUUWhU5k9moz0iuLPA/qLuQhn63vKMCWsGXlrw3LHeQAduKlB3kOJ+eCGKKe B7uNMFnI Rn8B/3vjbpBu/j+oIGAKD7/vPK0TK3T3r9Sl/LYhvTgQmBFxh9ZsguNe/0RRvZi+jaHyegNPJRvePw7VQ8gy0YOUCWYTlCOcqikMK1tj+HXsMdowrREYJk6gf25xCkU+hEd17/s4OMSaGFRzAtI+LDVogyzAKgvkkDy0J1XZcw/9g2JiiRTwXDMC1PmjOoqRVq9YZodxPUoqZLZfkHuoIkaT6ATIB56Zwx4umIfdeOlfH3NGmSjmn64hekguxvqDVVCk7QZP+rR5rXQnOKaZQ69KYpCXXmxgYXUIZGK2zotVombUUWIBV9+/fNAN1UnNL71LdbIrIS7Es3QDkI9OBr7sWEqnZg5IKia7QUnnHRD9skzLRoX6KxbReCiuhTmsuYMjqaG91nEozMyk= 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 10:54=E2=80=AFAM Mike Rapoport wr= ote: > > 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 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 kp= robes > > > 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. Thanks, Song