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 32015C43334 for ; Mon, 20 Jun 2022 16:04:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 868CD6B0071; Mon, 20 Jun 2022 12:04:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 818406B0073; Mon, 20 Jun 2022 12:04:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6B9BA8E0001; Mon, 20 Jun 2022 12:04:41 -0400 (EDT) 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 5948E6B0071 for ; Mon, 20 Jun 2022 12:04:41 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 3A1C460188 for ; Mon, 20 Jun 2022 16:04:41 +0000 (UTC) X-FDA: 79599087162.13.B460490 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id A313F1C00A6 for ; Mon, 20 Jun 2022 16:04:40 +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 ABD6B614B2 for ; Mon, 20 Jun 2022 16:04:39 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9764C3411C for ; 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=1655741078; bh=eH2GAASlt54g98N+vPQt3HAgdfH+Rj39/LZHtqyPJGg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=YwIyUAv+A0gNhM3hvTyyCs5HDy3+ph4447cL+y0J0BcH5WegfAyoY2KDgFXMJJJpI peciLURF7tGjTg97XsvU3y7N3tKK8I+olsSqLzNPSr10/uDtt4FWsRlTvjByK0gRVy hDnK/fgOXvdwoabGqDDSCIw9bTFKxyF3US4dPPh3+O2H2JG8BFZOpvQ9VrGuhXnOTT Qrz4WQtfD4SLAlhgPgHNnF4hVuRGJCQBtuazDUkPAgmzHZhwWFxIxKzk3dLzdD9jki 5S0TIIUG3TcPXyhhxY+4TzroeFoG0FiyCJmIJlfWwVUSf2UcN39joS9XpVSzXDeyIs Y4srX2hLK9zpQ== Received: by mail-yb1-f172.google.com with SMTP id l66so18320495ybl.10 for ; Mon, 20 Jun 2022 09:04:38 -0700 (PDT) X-Gm-Message-State: AJIora9KW0qAPfeYdRMGDYc0MTbzaJ+l1kQMNgVKn+dQqcTAB6syqL05 yTzT6u0T1gd2O/ZD3SzJN7vUEtlNmnhmcjkkItY= X-Google-Smtp-Source: AGRyM1t3VYOwecfPvJe+k+RvYpPl8MpH2EqIn2VWJHKicFq3ni6wZ+GIiVERVN6Aa2escSloM2PYmanZEqga4+4KDuE= 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" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1655741080; a=rsa-sha256; cv=none; b=eaXyEZjBPAbjjCCqdETuBtQG2y0G6BLbJ7covKzjuJqe54+q4LHIKoAP0Y5+rx4wJOxXaX TOqvvm2ViyGOJdliSFiE1z6A0OsymZV1wX0+qCYNFeuvRW3H996J4UkGFq+z6f7kJXtpye JrhuVMJBFMPwsJIIGO2IsOXKk8/S1T4= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YwIyUAv+; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf20.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=1655741080; 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=eH2GAASlt54g98N+vPQt3HAgdfH+Rj39/LZHtqyPJGg=; b=FLuh9Pvk5utIi5gCE9OXHSuA/GNf2/Un5X+q+yAOx4RTFLqDfOjeHoEJvg4GnUeEAXDNx0 zR17XuW5380zque8Ltf+DE3m9XDRae4pRVUlULtOjCvmbEeKoARcCChAJAgg4vQ/pck4kp mmRVIxPgwyAbi5aaFGZca3+4LWdoYus= Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=YwIyUAv+; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf20.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org X-Stat-Signature: cyp8cew9yy7jiywszn54gb7p9e4szssa X-Rspamd-Queue-Id: A313F1C00A6 X-Rspam-User: X-Rspamd-Server: rspam03 X-HE-Tag: 1655741080-473149 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 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