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 12EC9C4332F for ; Tue, 8 Nov 2022 18:20:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 97BE56B0072; Tue, 8 Nov 2022 13:20:24 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 92B4D6B0073; Tue, 8 Nov 2022 13:20:24 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81B5D8E0001; Tue, 8 Nov 2022 13:20:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 7283C6B0072 for ; Tue, 8 Nov 2022 13:20:24 -0500 (EST) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 1EB9A8056C for ; Tue, 8 Nov 2022 18:20:24 +0000 (UTC) X-FDA: 80111089968.12.B4CA142 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf30.hostedemail.com (Postfix) with ESMTP id A976780003 for ; Tue, 8 Nov 2022 18:20:23 +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 A812C61725 for ; Tue, 8 Nov 2022 18:20:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E79FC43140 for ; Tue, 8 Nov 2022 18:20:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1667931621; bh=rtPus4wZ9whzU+oiAjc7m/B0JaN/87L/+adLBYQJFzc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=MSNlWyZbp7qsniT41Li6RF7wO7rjH/pZ0XuUHMv7eX7Fs3tHz8xmhzCrBdOa1x7UB jIhRzsNSLeImmwOnjWMTxf1FR6RCfDTGD517gU/fXZa8pjYWHUikcy17JdSLb7TLM9 4m0SQhEyYbo/aHz/xpvalBAZqbseBvheOErOljdP6ndsW96zJ0KrgdkF+ICjk1j+q/ BgBPgYZdUQ3nEFXcJtBqWSmdWoBTZ31OJB+Q3wQ5uEMn3M9SV8yNqME7nz+/ReznJ2 KeZByYmQXgv84pzXbD3giU7QfP/8Or9i/JHWyvzews4L79iUiCcDWldtyYaRcCd1vA bAmTPUrwgta7g== Received: by mail-ed1-f51.google.com with SMTP id a67so23756778edf.12 for ; Tue, 08 Nov 2022 10:20:21 -0800 (PST) X-Gm-Message-State: ACrzQf3hXLMgaKc1sIjiPMivvTcUJTH10vAsSLHiEDIDjJZdTWxMswI1 MReAh55LBDFOqbybqAZqd3tNKR5Oq31goCni12k= X-Google-Smtp-Source: AMsMyM6iYjvdzGHCCoS4kLmmT6doFp9ubw6Wxyr+Bo5rqVVt66t7zkg/hWKq7Dw75jbx3Y0yoVrYIUeNbxyKYF9Ql4s= X-Received: by 2002:aa7:d710:0:b0:463:bd7b:2b44 with SMTP id t16-20020aa7d710000000b00463bd7b2b44mr40946450edq.385.1667931619739; Tue, 08 Nov 2022 10:20:19 -0800 (PST) MIME-Version: 1.0 References: <20221107223921.3451913-1-song@kernel.org> In-Reply-To: From: Song Liu Date: Tue, 8 Nov 2022 10:20:07 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH bpf-next v2 0/5] execmem_alloc for BPF programs To: "Edgecombe, Rick P" Cc: "mcgrof@kernel.org" , "peterz@infradead.org" , "bpf@vger.kernel.org" , "rppt@kernel.org" , "dave@stgolabs.net" , "Torvalds, Linus" , "linux-mm@kvack.org" , "hch@lst.de" , "x86@kernel.org" , "akpm@linux-foundation.org" , "Lu, Aaron" Content-Type: text/plain; charset="UTF-8" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667931623; 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=rtPus4wZ9whzU+oiAjc7m/B0JaN/87L/+adLBYQJFzc=; b=ufPGYvOTyGMD/DagnVGbCF8H8Eo+3ENqeKo9Pzit9idQy1Jbm+/aTXd+w/AIFqMncXwVv1 A9b1cI3QOWEVfU7mO1E27mNsFxzHaJLy2zI2SRKCdQAqWu9XgNvbK3wxSjeN63N2w/mmuD UgK4mAgpCMSK7uQL0vZ++c26l7QPscU= ARC-Authentication-Results: i=1; imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MSNlWyZb; spf=pass (imf30.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667931623; a=rsa-sha256; cv=none; b=NYyEdEnGHrBWu9limKi2tDh86WEFLdvZW/sZH9hSsDclrptT3P8DpQMDebaFviGLgEDvnl itennYyZuNtJXCu6MxxyYcS/cIkmgK/EpxNjUDf0vMPhyWUX2VC72GWwE9BBswQMQGtrbY IXOxGup++pVuVk4Mfizn/+VHkbS09G4= Authentication-Results: imf30.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=MSNlWyZb; spf=pass (imf30.hostedemail.com: domain of song@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=song@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: A976780003 X-Stat-Signature: q9wycmz6d4cxra5r4si5s3nxf9zcx8ci X-HE-Tag: 1667931623-66107 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, Nov 7, 2022 at 4:13 PM Edgecombe, Rick P wrote: > > On Mon, 2022-11-07 at 15:39 -0800, Luis Chamberlain wrote: > > On Mon, Nov 07, 2022 at 03:13:59PM -0800, Song Liu wrote: > > > The benchmark used here is identical on our web service, which runs > > > on > > > many many servers, so it represents the workload that we care a > > > lot. > > > Unfortunately, it is not possible to run it out of our data > > > centers. > > > > I am not asking for that, I am asking for you to pick any similar > > benchark which can run in paralellel which may yield similar results. > > > > > We can build some artificial workloads and probably get much higher > > > performance improvements. But these workload may not represent real > > > world use cases. > > > > You can very likely use some existing benchmark. > > > > The direct map fragmentation stuff doesn't require much effort, as > > was demonstrated by Aaron, you can easily do that or more by > > running all selftests or just the test_bpf. This I buy. > > > > I'm not buying the iTLB gains as I can't even reproduce them myself > > for > > eBPF JIT, but I tested against iTLB when using eBPF JIT, perhaps you > > mean iTLB gains for other memory intensive applications running in > > tandem? > > Song, didn't you find that there wasn't (or in the noise) iTLB gains? > What is this about visible performance drop from iTLB misses? > > IIRC there was a test done where progpack mapped things at 4k, but in > 2MB chunks, so it would re-use pages like the 2MB mapped version. And > it didn't see much improvement over the 2MB mapped version. Did I > remember that wrong? There is still a small gain (~0.2%) for this benchmark. Thanks, Song > > > > > And none of your patches mentions the gains of this effort helping > > with the long term advantage of centralizing the semantics for > > permissions on memory. > > Another good point. Although this brings up that this interface > "execmem" does just handle one type of permission.