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 3C1C6C43334 for ; Tue, 21 Jun 2022 02:51:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9A8006B0072; Mon, 20 Jun 2022 22:51:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 959ED6B0073; Mon, 20 Jun 2022 22:51:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 821BF8E0001; Mon, 20 Jun 2022 22:51:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 729076B0072 for ; Mon, 20 Jun 2022 22:51:39 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 4AF28120E5C for ; Tue, 21 Jun 2022 02:51:39 +0000 (UTC) X-FDA: 79600717518.16.E920A83 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf18.hostedemail.com (Postfix) with ESMTP id BBA3B1C001D for ; Tue, 21 Jun 2022 02:51:38 +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 F1112B81693 for ; Tue, 21 Jun 2022 02:51:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 997F0C341C4 for ; Tue, 21 Jun 2022 02:51:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1655779895; bh=irQwJk9q3lj6Mb5+MUo1cwVgd5N9WsMo25ESc2zJ6J0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=u9DRq3KoIUNrONpYTo1qOYf+0isutq+d5XZWuib5HhoWZ/ihZ99wcxCi7oWYJN3io isOYv+aPiOknPA+T6J5of/banzXpnT+DUA0R+te1QsGV431NTk9fEOliNr9WwZ0Oaq BeI3JLdUZHhHAWnaEdCNNbROimEc0V+J9i1OKGjvpIjeZ2cPY12ZGTjhUDD5y1zpl8 TxwbfpliGoYEc17Y9PkG5LK7Nh2aJPy7a2jLouLvCAlL12UuojjnvVvPBToyzx47PX LWupqkzWE01Cu2zAsshPpkQN+kFAQckBkHgMXTVSJGdSwk50Aa30j4KNwUPmpSP+Xa n90pycj5G7oAg== Received: by mail-yb1-f174.google.com with SMTP id l66so20738926ybl.10 for ; Mon, 20 Jun 2022 19:51:35 -0700 (PDT) X-Gm-Message-State: AJIora+MDPANQG7JUFayWDZ29/jleSaAgSlqIwyCNA8IDB5XB4+PRdbR yOM04K1umZRNk8RDckQpBodnmvUEV9QP3/X2wJk= X-Google-Smtp-Source: AGRyM1tXaEkWud44fl8OhCVPrRToQwsjs7ndHVzk7shodMzOvpkTKmiKcC4qpJLkG3P+e8gCuTh7QgATXlGGDBChqOE= X-Received: by 2002:a05:6902:b:b0:668:e2a0:5c2 with SMTP id l11-20020a056902000b00b00668e2a005c2mr13741839ybh.389.1655779894668; Mon, 20 Jun 2022 19:51:34 -0700 (PDT) MIME-Version: 1.0 References: <20220520235758.1858153-1-song@kernel.org> In-Reply-To: From: Song Liu Date: Mon, 20 Jun 2022 19:51:24 -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=1655779899; a=rsa-sha256; cv=none; b=ydUIxZ1i8Fgm1YKxRgkgf0vRhxSRoDF7YkprpSzz7gXKTuv6Tn4SgmZ0qZ6sTec9gDfcWL iOpJIlmY9GXe8n9moyRKrPB85WrQBd0WjRpKT/pqAuCEM842mWLrWAEIvd+14N/EwetlO2 4eZUBAGwod3YS934asLrbCimd/EGP+s= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=u9DRq3Ko; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 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=1655779899; 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=irQwJk9q3lj6Mb5+MUo1cwVgd5N9WsMo25ESc2zJ6J0=; b=SjqOGdmX4llN2s/S/515bTv1UN7LUwjnKLpxyLZtTmRIIpMtkp3Sn7OvKaLrl5cpQaZEMG FaS0dfJWqTIAFS3yQ81kGkIHgluytEZdhq24IUkNC2SfkwJxGQs17Pu4d91D4ALfC3bFi2 V5n+A2pj3Q/DlK/jWa8EU0pYlgg6kxE= X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: BBA3B1C001D X-Stat-Signature: pf53z9ntzqg1akgdiot6tb53qpjwkzfu X-Rspam-User: Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=u9DRq3Ko; dmarc=pass (policy=none) header.from=kernel.org; spf=pass (imf18.hostedemail.com: domain of song@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=song@kernel.org X-HE-Tag: 1655779898-377024 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 Mon, Jun 20, 2022 at 6:32 PM Aaron Lu wrote: > > On Mon, Jun 20, 2022 at 09:03:52AM -0700, Song Liu wrote: > > 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? > > Guess I didn't make it clear. > > I understand that set_memory_XXX() will cause direct mapping split and > thus, fragmented. What is not clear to me is, how much impact does > direct mapping fragmentation have on performance, in your case and in > general? > > In your case, I guess the performance gain is due to code gets packed > together and iTLB gets reduced. When code are a lot, packing them > together as a hugepage is a further gain. In the meantime, direct > mapping split (or not) seems to be a side effect of this packing, but it > doesn't have a direct impact on performance. > > One thing I can imagine is, when an area of direct mapping gets splited > due to permission reason, when that reason is gone(like module unload > or bpf code unload), those areas will remain fragmented and that can > cause later operations that touch these same areas using more dTLBs > and that can be bad for performance, but it's hard to say how much > impact this can cause though. Yes, we have data showing the direct mapping remaining fragmented can cause non-trivial performance degradation. For our web workload, the difference is in the order of 1%. Thanks, Song