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 6927EC433FE for ; Tue, 29 Nov 2022 17:27:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F8F76B0081; Tue, 29 Nov 2022 12:27:19 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A9A26B0082; Tue, 29 Nov 2022 12:27:19 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EDA5E6B0083; Tue, 29 Nov 2022 12:27:18 -0500 (EST) 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 E03206B0081 for ; Tue, 29 Nov 2022 12:27:18 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id B63E580C07 for ; Tue, 29 Nov 2022 17:27:18 +0000 (UTC) X-FDA: 80187160956.20.A746AB7 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf18.hostedemail.com (Postfix) with ESMTP id E64041C0013 for ; Tue, 29 Nov 2022 17:27:16 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 515F6B817B8 for ; Tue, 29 Nov 2022 17:27:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id D6414C4347C for ; Tue, 29 Nov 2022 17:27:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1669742833; bh=iid/8vh3EUYIxDWJZP5JTT0Tm2R53NAd0jgrlsysLt8=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=CHnMrLzyUZTrk8KiopgmFxgjd16a/ofzqqYNhgTOZ0wOT3CST29eTVT9MivKAbOG1 DBgY//ObUdC5L8RCtbFlICdgcBgdSyb+8sHyntupdNt7wDbJ56YOhRoW5LpzszFqUw I5uYdjofysBODji2zt2YNOZOK2glMoVvZT7oegtZPKhZL19cuwrQMc8UCnq/cZ8iQh PflWUUNIAcWwBQs1E1Bgva8gBtJWqeCp1lAERzECnHyB5SQIOQAMepqydU77ueILZc L2F815YH0CaaGSNZeZWZ0/ErOmb9KnUtblfyf4fa0d7Ruc3iaQFXpckYE2q0cVh0fN ubXtQidDIO3Og== Received: by mail-ed1-f41.google.com with SMTP id v8so20780347edi.3 for ; Tue, 29 Nov 2022 09:27:13 -0800 (PST) X-Gm-Message-State: ANoB5pmYo1xrFOBkGqFFMLoT/JwPQnALTZI5dJLDnAKwQO9nUye+oaqX MdaUS0OZLpC03B3nShLM1A4FtoQwahCkEPBTB2E= X-Google-Smtp-Source: AA0mqf5dCdcR2tfMGRyKt2WnqriIbdenku692I8TWK4kvHn6DPldz13+W5XJOMhYP4ocZfMXGwsuX54wPrM8MB3iAHg= X-Received: by 2002:a05:6402:240c:b0:462:2c1c:8791 with SMTP id t12-20020a056402240c00b004622c1c8791mr39316292eda.29.1669742832053; Tue, 29 Nov 2022 09:27:12 -0800 (PST) MIME-Version: 1.0 References: <20221107223921.3451913-1-song@kernel.org> <87lenuukj0.ffs@tglx> In-Reply-To: <87lenuukj0.ffs@tglx> From: Song Liu Date: Tue, 29 Nov 2022 09:26:58 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs To: Thomas Gleixner Cc: bpf@vger.kernel.org, linux-mm@kvack.org, peterz@infradead.org, akpm@linux-foundation.org, x86@kernel.org, hch@lst.de, rick.p.edgecombe@intel.com, aaron.lu@intel.com, rppt@kernel.org, mcgrof@kernel.org Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1669742837; 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=ywfE+TE2aekG9auw+IWcezF4BR8w+JOKmtpD0Pcsuh8=; b=x9mWb4VMsALwkGVxO2xYgYDmwRd9A8ckOHVFS2h4dto4jjl1ZzJpR6sQhNGuhnGKb6aPd7 zAXMY/ccw23Z9m3qFiE6WxD7mAIczYehWgCr0zKoivn3AuevexIcy0b4tREuGxEQ3grWNP PU5Tlm405yq4zUG8vP2SJlq/y3XJXg0= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=CHnMrLzy; spf=pass (imf18.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1669742837; a=rsa-sha256; cv=none; b=BYwrfKl3gCWln/3psdszG+7TQRRTrxVEwhaXu5GWgMAHRfmHRtL0wvNSgEhkHxCnsCOyR1 A8T/4nwYy4fxaTx6wyhLQT9FLIOiz/mwY+GC3FjBhtVAS3T4KUTDAZ3yogT1q3gLNR8e29 G4EgQ2EL2o8Bezm/A/zdKNkwDYPD/W0= X-Stat-Signature: ihop5mrkczjqt5mz5fje34tha7usirwr X-Rspam-User: X-Rspamd-Queue-Id: E64041C0013 X-Rspamd-Server: rspam11 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=CHnMrLzy; spf=pass (imf18.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-HE-Tag: 1669742836-785848 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: Hi Thomas, Thanks for your comments. On Tue, Nov 29, 2022 at 2:23 AM Thomas Gleixner wrote: > > 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. I am not sure I fully understand your point here. Do you mean 1) There is something wrong with this solution, that makes it not suitable for modules; or 2) The solution is in the right direction and it will very likely work for modules. But we haven't finished module support. ? If it is 1), I would like to understand what are the issues that make it not suitable for modules. If it is 2), I think a solid, mostly like working small step toward the right direction is the better way as it makes code reviews a lot easier and has much lower risks. Does this make sense? I would also highlight that part of the benefit of this work comes from reducing direct map fragmentations. While BPF programs consume less memory, they are more dynamic and can cause more direct map fragmentations. bpf_prog_pack in upstream kernel already covers this part, but this set is a better solution than bpf_prog_pack. Finally, I would like to point out that 5/6 and 6/6 of (v5) the set let BPF programs share a 2MB page with static kernel text. Therefore, even for systems without many BPF programs, we should already see some reduction in iTLB misses. Thanks, Song