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 ABCE2C4321E for ; Tue, 29 Nov 2022 14:01:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 37ABD6B0071; Tue, 29 Nov 2022 09:01:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 32A3F6B0074; Tue, 29 Nov 2022 09:01:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1F2906B0075; Tue, 29 Nov 2022 09:01:32 -0500 (EST) 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 108B96B0071 for ; Tue, 29 Nov 2022 09:01:32 -0500 (EST) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2FF1480EA4 for ; Tue, 29 Nov 2022 10:23:21 +0000 (UTC) X-FDA: 80186092602.27.86881D5 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) by imf16.hostedemail.com (Postfix) with ESMTP id 9599918000A for ; Tue, 29 Nov 2022 10:23:19 +0000 (UTC) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1669717397; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=znPXvxz3kz6ID7zX6kCLMH9Eop2P9SgAGV/kZSx6/e0=; b=V027JSBo5uFP6TX3Lf8rRrU22Mn2Pjay+3rXWjG0eexUWUDu2eAXFntcSOGMPMkLdmp54q C+NoyFUyKQ3fOjwmodIrCXckYziK7RMeuI20yHuygajK8VPtuMiAEaW4H5abRBP13IrZZl uCWwuNmJqBCB3v+T29EteeyL+yes0sj14iOiQQu0LQjSIlhMdFJAEbXBADoBbwS3masNmh m5lnuqb5YA+wk2iGi2SjpIiF+YnD5oAZoiXoT7zJzgtmKYKQakscZ5LkzSdVYKhQqTeYxK Iu9ictSeTcQ3gCd/QgSXJrSVjtMrCXEMGDyD+1H2lWvVSf/6AqzyrjT23u5qzQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1669717397; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=znPXvxz3kz6ID7zX6kCLMH9Eop2P9SgAGV/kZSx6/e0=; b=01fI197c3emeb97I5YstKIxQJ1dj0jh1u5z0sZBrc2ZfJ/vrmxeSbjCXlHzikUdSdDznoC vteyR0edggT5pUAw== To: Song Liu , bpf@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, akpm@linux-foundation.org Cc: x86@kernel.org, hch@lst.de, rick.p.edgecombe@intel.com, aaron.lu@intel.com, rppt@kernel.org, mcgrof@kernel.org Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs In-Reply-To: References: <20221107223921.3451913-1-song@kernel.org> Date: Tue, 29 Nov 2022 11:23:15 +0100 Message-ID: <87lenuukj0.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669717399; a=rsa-sha256; cv=none; b=4kwDnLkshTPx6w1M6JD4GQT6NArEL7P6j5IHUjG5Z2Hgm3gSHUt5ciunb/JJx7KljfehiK J+SP4vHa+ItBlN+Ipt7ycS37yxkl1juFCXRMNfu7yqNtPBV8PWXoLjMDllNmSpwYGgeWcF vd6nNWnuPdpnacBwP4m3OTgLawR4fIg= ARC-Authentication-Results: i=1; imf16.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=V027JSBo; dkim=pass header.d=linutronix.de header.s=2020e header.b=01fI197c; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf16.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669717399; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=znPXvxz3kz6ID7zX6kCLMH9Eop2P9SgAGV/kZSx6/e0=; b=5yEij+/u0pRM7Tfalt3GhEE+hVwbSS8Y6URnvjpLFEk0lz4lvQLFX0ePeW9bqU0H8EiGxT 9QdjDpPKF5ayFaGIy+W9hobGVbUin/gNeP8Ovfbo2E1WmlpXsq5omiY09GBBcqmUCJtsqy FmmmTAtywNfAG6bQO+dIOECQmlAFLgs= X-Rspamd-Queue-Id: 9599918000A X-Rspam-User: Authentication-Results: imf16.hostedemail.com; dkim=pass header.d=linutronix.de header.s=2020 header.b=V027JSBo; dkim=pass header.d=linutronix.de header.s=2020e header.b=01fI197c; dmarc=pass (policy=none) header.from=linutronix.de; spf=pass (imf16.hostedemail.com: domain of tglx@linutronix.de designates 193.142.43.55 as permitted sender) smtp.mailfrom=tglx@linutronix.de X-Rspamd-Server: rspam09 X-Stat-Signature: zaqzwicxb3em8ust1cs6sz6sjqu7f99b X-HE-Tag: 1669717399-407276 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: On Mon, Nov 14 2022 at 17:30, Song Liu wrote: > On Mon, Nov 7, 2022 at 2:41 PM Song Liu wrote: > Currently, I have got the following action items for v3: > 1. Add unify API to allocate text memory to motivation; > 2. Update Documentation/x86/x86_64/mm.rst; > 3. Allow none PMD_SIZE allocation for powerpc. > > 1 and 2 are relatively simple. We can probably do 3 in a follow up patch > (as I don't have powerpc environments for testing). Did I miss anything? > > Besides these, does this set look reasonable? Andrew and Peter, could > you please share your comments on this? This is a step into the right direction, but is it a solution which has a broader benefit? I don't think so. While you are so concerned about (i)TLB usage for BPF, I'm way more concerned about modules. Just from a random server class workstation: Total module memory: 12.4609 MB Number of 4k PTEs: 3190 The above would nicely fit into 7 or 8 2M mappings. Guess how much memory is occupied by BPF on that machine and how much BPF contributes to iTLB pressure? In comparison to the above very close to zero. Modules have exactly the same problem as BPF, just an order of magnitude larger. So we don't need a "works" for BPF solution which comes with the handwaving assumption that it could be used for modules too. We need something which demonstrates that it solves the entire problem class. Modules are the obvious starting point. Once that is solved pretty much everything else falls into place including BPF. Without modules support this whole exercise is pointless and not going anywhere near x86. Thanks, tglx