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;
Date:   Tue, 21 Jun 2022 09:31:46 +0800
From:   Aaron Lu <aaron.lu@intel.com>
To:     Song Liu <song@kernel.org>
CC:     open list <linux-kernel@vger.kernel.org>,
        bpf <bpf@vger.kernel.org>, Linux-MM <linux-mm@kvack.org>,
        Alexei Starovoitov <ast@kernel.org>,
        "Daniel Borkmann" <daniel@iogearbox.net>,
        Peter Zijlstra <peterz@infradead.org>,
        Luis Chamberlain <mcgrof@kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>,
        Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v4 bpf-next 0/8] bpf_prog_pack followup
Message-ID: <YrEfghUwr+IO2MM1@ziqianlu-Dell-Optiplex7000>
References: <20220520235758.1858153-1-song@kernel.org>
 <YrBV8darrlmUnrHR@ziqianlu-Dell-Optiplex7000>
 <CAPhsuW5oqJKHUr6wwbFyC8DFyawKr8djuv5Bjk7FEQ5dnKDGyw@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAPhsuW5oqJKHUr6wwbFyC8DFyawKr8djuv5Bjk7FEQ5dnKDGyw@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?OdFuG9bDwh5LOjgOTQkv/xjSDilzotYC1zayu4QXFYQB30Xja015NpiJZa4U?=
 =?us-ascii?Q?T95zla81Sr8YsHo8btsinpmWYtIGsZQTD8mG9OrEcsyRkbo16012XO3NOSB5?=
 =?us-ascii?Q?0K79fuLjudObd9+1OCnBnAvCxez44/9p6IXwM/pTikFPFCuy/S+cdyrZqLfH?=
 =?us-ascii?Q?m4maM2/O0A0Tntu2kARufKoM2pTzq97WdxE5Af21mthwyL/ZzmkcWNJfQoQS?=
 =?us-ascii?Q?Mko5Sx+w3vIaHxQfzr/leHQd36zFnr6OIq6jvcCLO6GthYjMPnpS/qbZTmSA?=
 =?us-ascii?Q?2X4Mds2urv/Jcldvr8MRA9QmLMpYSnboDIrJksQ4wbOo8sYC2q/0ZK0u+ta1?=
 =?us-ascii?Q?xp7+S8btKD+tOvbyjbaXKjJTryFvU7a+gRYBy+S3ogGE55spmDZjPHKzG5MW?=
 =?us-ascii?Q?Hr1LBjkmn1fVk48VBaJKg3VgcnrAys9X1ozgRNZrKYwitLIyL00tFOPrmrN0?=
 =?us-ascii?Q?pqzdwd+knGhoWX9l9Tf0Q2M9LD3IEKncc2eQExVje/47g0Vm+6/fEpmH+bR0?=
 =?us-ascii?Q?BviFI2P4A8hfq/+kM7qF6Hgt/BkloB6/2W1p74ZbjwE2xvUQMN2BT5NSgSs2?=
 =?us-ascii?Q?Bxfz0RtMrGMIXZYsLR/12YaYRAhPhjHyHZFUkhTWPukf/hJgRZEEOF5FViuC?=
 =?us-ascii?Q?ZOrNRq4p5Q1j7Q7VZilDcLb7kbVqGzxXnWAzoSoqQsUxPqHuF6310ZBlhOWH?=
 =?us-ascii?Q?gDtc9NMCXqTKWtaeirTiG1DBZLBkAeSd2OYFccHMP9MVuydVpjB6d4ehDkvp?=
 =?us-ascii?Q?CXwNNJLTJEc4kzgh5kIwUiXodwoFD3R08LLNfmWnmuZeScnqnMxeHilbGkIe?=
 =?us-ascii?Q?eh4NKNoZwpEOvmqbndbah/sF1x5+pvzT5T7P7omoE1g229ziglO/SMf+ldaS?=
 =?us-ascii?Q?nfs4HIzs7ZhyQzGZ23QE2eUHKtC1YuQuXKZ75SJvgwlcQkKGpd2y879tusL3?=
 =?us-ascii?Q?VzoGXvdVPBsAgidzxsxRsNCrwUvCCmIqWO23Xu0A2wzEZgXfSq0303EP88T2?=
 =?us-ascii?Q?Ef2pVUv9yK5te7+AG/44bxmkbQPQAIDKfPvRmSHz2Y6trMIRJ0v+dpHmzgN7?=
 =?us-ascii?Q?eBbUl6hQTPEkcpgYfv3ev6IJUvy7vE255wLnXRp00Eb0PBb/iBlmzutaeq0j?=
 =?us-ascii?Q?jmVWl126bSHlNSwuxyth7SW0juK1Sgs5Kq2HqstVK9buKg5FgsnLvSM4LUMy?=
 =?us-ascii?Q?MK6r9R0GXNEDP8alXpLwuEYQHfRR+B2PDtppylnWNde8KtRh2Ujsks7rgxOk?=
 =?us-ascii?Q?qUxlwPcyBWi5o+4jW34lc6DknKKTlPt8GIaZXo6o6OrO0+nqwtagX+D/BGCT?=
 =?us-ascii?Q?eLly4WT6w5XS4qAftEbuAQBtN+9aWix8Uzxbzgfayn3COLM+d32lgXJGc8Sj?=
 =?us-ascii?Q?zY583H1b7Y3Ju5QVZcsLcCMGIzOJWE5ILNIJ8rvq9I5WZwMBV4eorMxL64mD?=
 =?us-ascii?Q?mxwyNMvmZ3zQHLb1xsVvjCM0CrnuT4OlkQ8mxt9KFTQfS8iKyF7hudhAtq9J?=
 =?us-ascii?Q?j87GMTkwh0vE0/kOfoFW2q45PMVZtUYuPCFVeZBG4i+nzIs/Wycr9594t4pI?=
 =?us-ascii?Q?kz2BjTrp/ic6FPi9bA1oD0MNdVX5xzFP5udPwGSvU6JA1eKipXuM1vuXdxMv?=
 =?us-ascii?Q?XQGYlUFtHmxneIls0eTfgL6BXWA5sf3+RWG+DDJHf3i12iyivcMXgMXej84j?=
 =?us-ascii?Q?cPERtU8CWvfqkw6QUTp7Lw2gXsXh9QEJto5VxLto+dB6Z4STuIho/Zoq4Rya?=
 =?us-ascii?Q?tfGwGXi2lw=3D=3D?=
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d7a51bc-92ab-4aef-be99-08da5325d7a3
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3062.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jun 2022 01:32:02.4949
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: zspN84/KB+M5cW9cQTlII6mfdSkYyrFwLYSZZkvLhSg5vH/UckKjjpXt+cVSsbOixteEjA6/CCgx8CvzY5HaQg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2617
X-OriginatorOrg: intel.com
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,
        RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        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: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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 <aaron.lu@intel.com> 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.

Regards,
Aaron