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 2A4C9C4332F for ; Thu, 17 Nov 2022 01:52:48 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92C608E0001; Wed, 16 Nov 2022 20:52:47 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8DC846B007B; Wed, 16 Nov 2022 20:52:47 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A3CB8E0001; Wed, 16 Nov 2022 20:52:47 -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 675256B0075 for ; Wed, 16 Nov 2022 20:52:47 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 3C9B5809AE for ; Thu, 17 Nov 2022 01:52:47 +0000 (UTC) X-FDA: 80141260374.02.640EE09 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf29.hostedemail.com (Postfix) with ESMTP id DBC1F120011 for ; Thu, 17 Nov 2022 01:52:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=SWLJosgcIf0vVkoGa4k8mju9fQuM7WliqRBO2ZQYrgU=; b=WrRZAhfYVZc27BXTl7CY+wFCfv aadi8DqdxIaglejyMCzJLCfimXQgDtxx/qW7jKfjZvG3q34WGaXH8a17jb8kLUntq0QFTQiSWt3xe Yxgf4eWdOYPV/dc+JcP2YIGf5dLDrQn6R79kRPiDluwOA8VFu4Y9A3Wglxi+J2v8nMgivLVP+lR0w ksxKWpCwwFnNrZbcU4Rum350/ntYA5ZU+ZxDmTUROyjVx2WtGSERLO59v5qZvjtpKmBiqsx/8Qfgx uh9PPnFdRf6m4yzB4Rl2viMqaJdfviaIw3fEI4Es7xhVx+miS4ix2uLdMbf8vhpQspDoPUIg7mr64 z3mWKOnA==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1ovU54-009PgA-Lo; Thu, 17 Nov 2022 01:52:42 +0000 Date: Wed, 16 Nov 2022 17:52:42 -0800 From: Luis Chamberlain To: Song Liu Cc: bpf@vger.kernel.org, linux-mm@kvack.org, akpm@linux-foundation.org, x86@kernel.org, peterz@infradead.org, hch@lst.de, rick.p.edgecombe@intel.com, aaron.lu@intel.com, rppt@kernel.org Subject: Re: [PATCH bpf-next v3 4/6] bpf: use execmem_alloc for bpf program and bpf dispatcher Message-ID: References: <20221117010621.1891711-1-song@kernel.org> <20221117010621.1891711-5-song@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221117010621.1891711-5-song@kernel.org> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668649966; h=from:from:sender: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=SWLJosgcIf0vVkoGa4k8mju9fQuM7WliqRBO2ZQYrgU=; b=CUJU304c6Fakc05iC0x7f/ZvTgWNX3aLU9HCgrFQwku/u4OKvLZftVSm5JtzxQ3vfroKBf A0bSck/7+V4aKOEJHKIiguXDd6lflU4xRgdkD1NWx0LofAQiOskoAp/MfFFoiOAeCtQFnm 1ZnX4EZvgB6CWbfpSZU9ez9gP4v2raQ= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=WrRZAhfY; spf=none (imf29.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668649966; a=rsa-sha256; cv=none; b=0S7sZILfCZr+gQ6/jfPF/x5N8/ELlJSwL/mnMbMsC6RsclRecbKdiTe0pOWeSBsM9xgKly Z05x5BhnRVRNO2d8F5c0Br1j38TmgoRfiRD6PUYmKY//28DITEn1dvfBNtyUznINWIiDb3 qxH+wRARlky47HoO2NIP3oUKoCADCWo= X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: DBC1F120011 Authentication-Results: imf29.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=WrRZAhfY; spf=none (imf29.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) X-Stat-Signature: tqo5717af41yktdasey7ycpkttj765dp X-HE-Tag: 1668649966-123051 X-Bogosity: Ham, tests=bogofilter, spamicity=0.001551, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Wed, Nov 16, 2022 at 05:06:19PM -0800, Song Liu wrote: > Use execmem_alloc, execmem_free, and execmem_fill instead of > bpf_prog_pack_alloc, bpf_prog_pack_free, and bpf_arch_text_copy. > > execmem_free doesn't require extra size information. Therefore, the free > and error handling path can be simplified. > > There are some tests that show the benefit of execmem_alloc. > > 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 Wonderful. It would be nice to have this integrated into the bpf selftest, instead of having to ask someone to try to repeat and decipher how to do the above. Completion time results would be useseful as well. And, then after try running this + another memory intensive benchmark as recently suggested, have it run for a while, and then re-run again as the direct map fragmentation should reveal that anything running at the end after execmem_alloc() should produce gravy results. Luis