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 00FE7C433FE for ; Tue, 15 Nov 2022 22:48:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 70DC66B0071; Tue, 15 Nov 2022 17:48:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6BDF98E0001; Tue, 15 Nov 2022 17:48:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 586286B0073; Tue, 15 Nov 2022 17:48:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 493B56B0071 for ; Tue, 15 Nov 2022 17:48:22 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 14A08AAAFA for ; Tue, 15 Nov 2022 22:48:22 +0000 (UTC) X-FDA: 80137166844.23.D199A05 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf06.hostedemail.com (Postfix) with ESMTP id A4AD9180002 for ; Tue, 15 Nov 2022 22:48:21 +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 dfw.source.kernel.org (Postfix) with ESMTPS id BA30961383 for ; Tue, 15 Nov 2022 22:48:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 27948C43141 for ; Tue, 15 Nov 2022 22:48:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1668552500; bh=wQL+xHNCPKSUFwCdVx1cMXkXXK9eEwbzs4XS2WDmu18=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OUZ1hFQqxemfvGC/Y++tHo/zhL4a9JbeqDi4IK5KekndFpWHw3XEz0p8e1Pj3htE0 nrpNpFyG3XzCyfpvMSS87w/d8CbnfalYsrxnLOBdOunCMg0R3fieGFNmYxcfttjc2N LipCZ/Vx0cTZoYHultkkA4MP+ew46kqRQwJG5tCRfmB8L0nQhKsLhm2e5eZPjO2yvn LXmkhHXOJ+tfBXmZmtErexfvKb5rZiqecN5vru0Y+6ZqZjgibnMGL0rJ4Xpy7qYhuB 1GZ6HIFtaeWkn1GXjw2uqjFTl8juOW/h/p6SrJddFBf9upKaKC5rx0r7bZu2o4+o8C 3Pkik1y91rVSA== Received: by mail-ej1-f46.google.com with SMTP id bj12so39799135ejb.13 for ; Tue, 15 Nov 2022 14:48:19 -0800 (PST) X-Gm-Message-State: ANoB5pnWWVaARCgvYh9imUDpw4RIkLRYaJqBUK+WuiYBCpuL/irILG6V 9uZFZuTgF6sjfLLkE5ea+5mg+XwjnMk+h2tTVjw= X-Google-Smtp-Source: AA0mqf5itU5yMzDGNj0IZlY//SCl9lKN9pPcDJZXZ+RL9AYOiWjStFmK2GvbGS0LSSCv+wKJFwyY8DyuUP5yKVPQcU0= X-Received: by 2002:a17:907:9618:b0:78e:17ad:ba62 with SMTP id gb24-20020a170907961800b0078e17adba62mr15611407ejc.719.1668552498267; Tue, 15 Nov 2022 14:48:18 -0800 (PST) MIME-Version: 1.0 References: <20221107223921.3451913-1-song@kernel.org> In-Reply-To: From: Song Liu Date: Tue, 15 Nov 2022 14:48:05 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs To: Luis Chamberlain 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 Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668552501; a=rsa-sha256; cv=none; b=Ogjd9nceTNy1JcrAlKM4Tf063a5Jvk4e+iHNTIyqfgPT1OC2NfnKGCmVVgxPGROhuiR5G1 nueFP9dH38ieOFespu4pQhLtVXCfIPyRhYGbtqGW582lv4k0Lqn/MShtWrPWA+7K1BPjJt UB/OOVF4eOdC4AnnueDACKc+ZciShog= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OUZ1hFQq; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf06.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 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=1668552501; 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=CIlNE7/Tr6pEhJxerBtdyoKH5SQGwMbY9twP1mKDwXU=; b=dvxjN5jGG276OPlmhBMkYxwtDHLjDA3Zc9g+7XOH8nq1WR+ZaXBrO/wN6AK/peF3NUWZck s64TuKnIguARkYISli11iSRGHrY37U3CHr7yq2rO9x89zTlXA+q+khiDftpgrWXFrlkqTd syAotNM38Tkrz+UJk0MCH+sONDGtq0Q= X-Stat-Signature: 5nq35ra1bf4ategbbtfpnoxddj16qfia X-Rspamd-Queue-Id: A4AD9180002 X-Rspam-User: Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=OUZ1hFQq; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf06.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org X-Rspamd-Server: rspam09 X-HE-Tag: 1668552501-746283 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 Tue, Nov 15, 2022 at 1:09 PM Luis Chamberlain wrote: > > On Mon, Nov 14, 2022 at 05:30:39PM -0800, Song Liu wrote: > > On Mon, Nov 7, 2022 at 2:41 PM Song Liu wrote: > > > > > > > [...] > > > > > > > > > > > This set enables bpf programs and bpf dispatchers to share huge pages with > > > new API: > > > execmem_alloc() > > > execmem_alloc() > > > execmem_fill() > > > > > > The idea is similar to Peter's suggestion in [1]. > > > > > > execmem_alloc() manages a set of PMD_SIZE RO+X memory, and allocates these > > > memory to its users. execmem_alloc() is used to free memory allocated by > > > execmem_alloc(). execmem_fill() is used to update memory allocated by > > > execmem_alloc(). > > > > Sigh, I just realized this thread made through linux-mm@kvack.org, but got > > dropped by bpf@vger.kernel.org, so I guess I will have to resend v3. > > I don't know what is going on with the bpf list but whatever it is, is silly. > You should Cc the right folks to ensure proper review if the bpf list is > the issue. > > > 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. > > - I am really exausted of asking again for real performance tests, > you keep saying you can't and I keep saying you can, you are not > trying hard enough. Stop thinking about your internal benchmark which > you cannot publish. There should be enough crap out which you can use. > > - A new selftest or set of selftests which demonstrates gain in > performance I didn't mean to not show the result with publically available. I just thought the actual benchmark was better (and we do use that to demonstrate the benefit of a lot of kernel improvement). For something publically available, how about the following: Run 100 instances of the following benchmark from bpf selftests: tools/testing/selftests/bpf/bench -w2 -d100 -a trig-kprobe which loads 7 BPF programs, and triggers one of them. Then use perf to monitor TLB related counters: perf stat -e iTLB-load-misses,itlb_misses.walk_completed_4k, \ itlb_misses.walk_completed_2m_4m -a The following results are from a qemu VM with 32 cores. Before bpf_prog_pack: iTLB-load-misses: 350k/s itlb_misses.walk_completed_4k: 90k/s itlb_misses.walk_completed_2m_4m: 0.1/s With bpf_prog_pack (current upstream): iTLB-load-misses: 220k/s itlb_misses.walk_completed_4k: 68k/s itlb_misses.walk_completed_2m_4m: 0.2/s With execmem_alloc (with this set): iTLB-load-misses: 185k/s itlb_misses.walk_completed_4k: 58k/s itlb_misses.walk_completed_2m_4m: 1/s Do these address your questions with this? > > - Extensions maybe of lib/test_vmalloc.c or whatever is appropriate to > test correctness I will look into this. > > - Enhance commit logs to justify the *why*, one of which to hightight is > providing an API for memory semantics for special memory pages And this. Thanks, Song