From patchwork Fri Jul 14 17:08:47 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alexander Lobakin X-Patchwork-Id: 120572 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:a6b2:0:b0:3e4:2afc:c1 with SMTP id c18csp2646113vqm; Fri, 14 Jul 2023 10:20:33 -0700 (PDT) X-Google-Smtp-Source: APBJJlEkazCK20drULLznD1WH3nLM+DzufSz55i6w6T8yOTc0wd+7MFq7RVbNq6wIyIMcMGkx/UM X-Received: by 2002:a05:6a20:387:b0:133:6f5e:e58 with SMTP id 7-20020a056a20038700b001336f5e0e58mr3457839pzt.33.1689355232911; Fri, 14 Jul 2023 10:20:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1689355232; cv=none; d=google.com; s=arc-20160816; b=eNU1R+Toninz+bGHGR3k2pnP4C9PiDCosibJ8GZaSfs5GCnmvq6N1kHER019w9ogAL dM6rrf7nZtRJR7H83/5T1XQd1TzrEHglKeD9apQ5nTaXfeEfq3jZ15EopZEPgZTJB/if OTmqKIvz+Z5CjgwCMskeSwhPsiLxsPQXnBlEkXVb9Qk3GqlIG3YVH/Rc6NfT3BKxvS7z h9uv1+qjZXLlUFkvp/GjI1EagTTffZyCm/txgKAvKs7PBiXagKR65oVzn/6iW1y7WeaJ gZoB96tcYw0PqIZqRDNCfO5Iw5c1CuVLHi+3ymBKy3IstvvL4xmQqxW2wyugA+HpQRiC Q5Ow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ftqWoVinUzKoSLBY29qjyNcT412KvJf9Bs4TXDpJNG8=; fh=A5BPnNIfRqU38T74SnJN3mZ6ktDaFB2zVWcmAifDomI=; b=DmdTVWkMgJNbrN6wU2UfoZ91vjXj1FhpJ8kg+p0sZlN5/4modKTWQnYUMCmTys3kLS ZAm4FALuKoNKsfVzHGjYhdWCVHknvBnuzTqf+UQRKN1fY+JQlOu8S8gf0uEBhbkbStIe UoXg9LtGL4y2A3J/RV4ZAa+D61TPGxtRlD7K3u7X2VEc5IUEgqWR2mbTW5vNEAwZralV C5Pbv9gGJ8KXeDNTFS4zfAgLqy+jc13W8vGpP9GbBJu3EpjZ36qMlcT9xSV7PNyXbr6H PO9KaaRU/1zEgmUY8mihJxRruwCggwOXMfjvx5mUpqybt/S8Yfs8bxefoU9XYR/ahl27 bJwQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=Djg7n3Fv; 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=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c5-20020a6566c5000000b0055fd97bff1csi126290pgw.760.2023.07.14.10.20.20; Fri, 14 Jul 2023 10:20:32 -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=@intel.com header.s=Intel header.b=Djg7n3Fv; 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=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236121AbjGNRKt (ORCPT + 99 others); Fri, 14 Jul 2023 13:10:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39250 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236098AbjGNRKk (ORCPT ); Fri, 14 Jul 2023 13:10:40 -0400 Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 50C973A87; Fri, 14 Jul 2023 10:10:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1689354634; x=1720890634; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=J4oLah63yJ0HDb0vEWkMBT8p/z6UYrzti87G1AcWpXY=; b=Djg7n3Fvxdp8jvnHwfgU+PhHXskCmVElSd0peTEQ/YySImKS2ctG6OCE Ds23HmqEOZ27Dwn4SB47086yrerxQLBDG1emJAqXshENxJrBtGDnpZ0tG RXKMperp9IsnTHwmqpOIJfR2/Eb3jcoamx6Ac/+KRCcHX5xiv/dPxIpKc 9aGHYrU/LeVCAYDdLlAvkeA27g7WNGXSc3vq2MgxXvy/YqQACqEeeEGes ZtL/+OCfeqJHUnhnGRcJdf5ttydkethQhAIrsXJqDR6qfc2KyqR/96DTo YK9wCqBtVVzTsOVZMSaB31XZDyRtHc6oAlrUnT6IB1qgP24VnSkzc1GLs Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10771"; a="451891877" X-IronPort-AV: E=Sophos;i="6.01,206,1684825200"; d="scan'208";a="451891877" Received: from fmsmga008.fm.intel.com ([10.253.24.58]) by fmsmga105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jul 2023 10:10:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10771"; a="787907035" X-IronPort-AV: E=Sophos;i="6.01,206,1684825200"; d="scan'208";a="787907035" Received: from newjersey.igk.intel.com ([10.102.20.203]) by fmsmga008.fm.intel.com with ESMTP; 14 Jul 2023 10:10:30 -0700 From: Alexander Lobakin To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Alexander Lobakin , Maciej Fijalkowski , Larysa Zaremba , Yunsheng Lin , Alexander Duyck , Jesper Dangaard Brouer , Ilias Apalodimas , netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH RFC net-next v2 3/7] net: page_pool: place frag_* fields in one cacheline Date: Fri, 14 Jul 2023 19:08:47 +0200 Message-ID: <20230714170853.866018-5-aleksander.lobakin@intel.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: <20230714170853.866018-1-aleksander.lobakin@intel.com> References: <20230714170853.866018-1-aleksander.lobakin@intel.com> MIME-Version: 1.0 X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE,URIBL_BLOCKED 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 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1771416879344152147 X-GMAIL-MSGID: 1771417352778250864 On x86_64, frag_* fields of struct page_pool are scattered across two cachelines despite the summary size of 24 bytes. The last field, ::frag_users, is pushed out to the next one, sharing it with ::alloc_stats. All three fields are used in pretty much same places. There are some holes and cold members to move around. Move frag_* one block up, placing them right after &page_pool_params perfectly at the beginning of CL2. This doesn't do any meaningful to the second block, as those are some destroy-path cold structures, and doesn't do anything to ::alloc_stats, which still starts at 200 byte offset, 8 bytes after CL3 (still fitting into 1 cacheline). On my setup, this yields 1-2% of Mpps when using PP frags actively. When it comes to 32-bit architectures with 32 byte CL: &page_pool_params plus ::pad is 44 bytes, the block taken care of is 16 bytes within one CL, so there should be at least no regressions from the actual change. Signed-off-by: Alexander Lobakin --- include/net/page_pool.h | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/include/net/page_pool.h b/include/net/page_pool.h index 69e822021d95..68937deea4b1 100644 --- a/include/net/page_pool.h +++ b/include/net/page_pool.h @@ -131,16 +131,16 @@ struct page_pool { struct page_pool_params p; long pad; + long frag_users; + struct page *frag_page; + unsigned int frag_offset; + u32 pages_state_hold_cnt; + struct delayed_work release_dw; void (*disconnect)(void *); unsigned long defer_start; unsigned long defer_warn; - u32 pages_state_hold_cnt; - unsigned int frag_offset; - struct page *frag_page; - long frag_users; - #ifdef CONFIG_PAGE_POOL_STATS /* these stats are incremented while in softirq context */ struct page_pool_alloc_stats alloc_stats;