Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3036203iog; Mon, 20 Jun 2022 09:48:33 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tlEk8YeSq/nwgGvnYHE1Yn0grji+/fg0EtRVIn40LhSi35DdfSStNWzBxPAxZmlcjDU9Ax X-Received: by 2002:a17:906:a10e:b0:6f3:e70b:b572 with SMTP id t14-20020a170906a10e00b006f3e70bb572mr20868604ejy.546.1655743713330; Mon, 20 Jun 2022 09:48:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655743713; cv=none; d=google.com; s=arc-20160816; b=SCeMNPjomc7fzof7me5YI5kjinnS2IOsOtl8g5s1ict9BjzGf4VCCNLfRMSBBdVdEH clpuZgZwe69HavKb5CCls7voLonG6vAHUcYREj49TOcRO3UBPjGViB0vN2Qv/PI0xuTo s3uLhNmevEWR3fc8MS+JcZNdXRKTRaXlIDtCncLQM+92tDrle4Pdxm+gLyXS1iANEqaj qeht2UKh12qm3l844RNXSfzxq2HCP+jWK6CjUERrwk0WiLkpUjj5Ojg0z1ncNg6fVKEI LUGKTJb4+9HwATN5IojrYAZNQgNZWdD6Rky4yl6vJwFXDq51UZXSpE5PBLwBP+UbA552 E+GQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=eH2GAASlt54g98N+vPQt3HAgdfH+Rj39/LZHtqyPJGg=; b=sV0YzwkO/u2slea9rvUw9e9V+Gs5cjluNLxDZqk5FA6IXYqeu+gn0LQ2jWlfo/2pk6 6nekHAR2svvnmpLEau1G4CpZtsi0TLkpjZoZ6nbGKyZJrAyWnttuhJOD0wEQU2BYPSLp 7cMxWwieK7gOI4L+OgfdQJ1QL3DERUKwyk2pY1EHJnqcpzLC6MtklEoGj8hcuH1/sMpv g3iMUsif0L272tiMv05Ur355fegwvLbvonOwMDl/EE7nrN38gpbxMXB+Ht//KqbLhABN AvzyDdWTbvG7ACgRmwIvFnKG+AVRgUg0u46tzIuAAHvT84z4CJoKLS9ufge+GZEV4nOj Aw3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hnsu4BBC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id du10-20020a17090772ca00b00711f646bb8csi11673395ejc.916.2022.06.20.09.48.07; Mon, 20 Jun 2022 09:48:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=hnsu4BBC; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243953AbiFTQEo (ORCPT + 99 others); Mon, 20 Jun 2022 12:04:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60720 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229487AbiFTQEn (ORCPT ); Mon, 20 Jun 2022 12:04:43 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 22B561FCFE; Mon, 20 Jun 2022 09:04:40 -0700 (PDT) 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 AD79C614B3; Mon, 20 Jun 2022 16:04:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id EE0ACC341C5; Mon, 20 Jun 2022 16:04:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655741079; bh=eH2GAASlt54g98N+vPQt3HAgdfH+Rj39/LZHtqyPJGg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hnsu4BBCJ2zky9wcC/uFViHVphj2A2MpjRV6/EupRfzqi+8ZEPa2dsC45cK2A5psD vijAeGH9A1TgC8SpFuqH97VaF8bNuH+yWjuWaG85U+lum4BfEBdV2xDUadAKytV2nQ 4QEDH/l/E4HGaOBoB6rl+1KITrBddWPF9ic+Rhk06MA10ABx5EVfoHDuWdXVRlMkOE S5xnGWOoLjbPhKtGt0+Tkwq/gCOGunDxj09k3ja7PBXCLQv4qfin+R3IzM8CG0xZhK cIgZC4in3kJjgI7U6Y0RZZDySg93f71s06R1ezjxfxaJqjwDzkgpKD0zUSrRGdEt1X L0ftpdSCIQQOw== Received: by mail-yb1-f172.google.com with SMTP id i15so14918211ybp.1; Mon, 20 Jun 2022 09:04:38 -0700 (PDT) X-Gm-Message-State: AJIora/ap3LOX2+NA+d9Bw7oCs409zESst2dIgbXJ+dZgDn+hGE9BP5V CrjkJyuRw9DAleLhiG6l9izX/ZF21UnfDPkIKsI= X-Received: by 2002:a05:6902:114c:b0:641:87a7:da90 with SMTP id p12-20020a056902114c00b0064187a7da90mr27215793ybu.561.1655741078011; Mon, 20 Jun 2022 09:04:38 -0700 (PDT) MIME-Version: 1.0 References: <20220520235758.1858153-1-song@kernel.org> In-Reply-To: From: Song Liu Date: Mon, 20 Jun 2022 09:03:52 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v4 bpf-next 0/8] bpf_prog_pack followup To: Aaron Lu Cc: open list , bpf , Linux-MM , Alexei Starovoitov , Daniel Borkmann , Peter Zijlstra , Luis Chamberlain , Linus Torvalds , "Edgecombe, Rick P" , Kernel Team Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Aaron, On Mon, Jun 20, 2022 at 4:12 AM Aaron Lu wrote: > > Hi Song, > > On Fri, May 20, 2022 at 04:57:50PM -0700, Song Liu wrote: > > ... ... > > > The primary goal of bpf_prog_pack is to reduce iTLB miss rate and reduce > > direct memory mapping fragmentation. This leads to non-trivial performance > > improvements. > > > > For our web service production benchmark, bpf_prog_pack on 4kB pages > > gives 0.5% to 0.7% more throughput than not using bpf_prog_pack. > > bpf_prog_pack on 2MB pages 0.6% to 0.9% more throughput than not using > > bpf_prog_pack. Note that 0.5% is a huge improvement for our fleet. I > > believe this is also significant for other companies with many thousand > > servers. > > > > I'm evaluationg performance impact due to direct memory mapping > fragmentation and seeing the above, I wonder: is the performance improve > mostly due to prog pack and hugepage instead of less direct mapping > fragmentation? > > I can understand that when progs are packed together, iTLB miss rate will > be reduced and thus, performance can be improved. But I don't see > immediately how direct mapping fragmentation can impact performance since > the bpf code are running from the module alias addresses, not the direct > mapping addresses IIUC? You are right that BPF code runs from module alias addresses. However, to protect text from overwrites, we use set_memory_x() and set_memory_ro() for the BPF code. These two functions will set permissions for all aliases of the memory, including the direct map, and thus cause fragmentation of the direct map. Does this make sense? Thanks, Song