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 737FDE77173 for ; Sun, 8 Dec 2024 21:35:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C69BB6B0394; Sun, 8 Dec 2024 16:35:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BF2D76B0395; Sun, 8 Dec 2024 16:35:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A93896B0396; Sun, 8 Dec 2024 16:35:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 8780F6B0394 for ; Sun, 8 Dec 2024 16:35:18 -0500 (EST) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 2E9A5140AAC for ; Sun, 8 Dec 2024 21:35:18 +0000 (UTC) X-FDA: 82873097286.10.DEE20B4 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf25.hostedemail.com (Postfix) with ESMTP id F34E6A0014 for ; Sun, 8 Dec 2024 21:35:01 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HDjrPuak; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733693697; a=rsa-sha256; cv=none; b=acufmIdkd4iUn3L9GydDO/oKnpDTpX8gBcCsCx8i6l5CEEPVVqetE2hr1+VO4IssBUZJJX npfak6JuaMdFqwcvBUqJv+tFlp9yDQ7jmQx8sXeVFqj9Jx7DadxvmrADaPSfz792lh9fDe 8rbvOPqJQfRGHOX18ACkufnHJcr1xqM= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=HDjrPuak; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf25.hostedemail.com: domain of alexander.duyck@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=alexander.duyck@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733693697; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0FT/XI9a4IlI8yhoJOXSguOkbtT9kvc9FGR93LWbKUw=; b=WtGbXyf01WRzAySOtBp2t1SL+r8WrePowSBSfAV3U7v5uENWGy107QXSaU+wx0tpFTUDlq hclqFihN1KgD1y8KLyVDMndT/uNt87iJN3TPfVvHVm+Aexirzyv4ZiDNcscpxB1zKBts78 lPBZmtsjBcHW2S8CKHuqBQKmFgWJD+0= Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-3863703258fso579822f8f.1 for ; Sun, 08 Dec 2024 13:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733693715; x=1734298515; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=0FT/XI9a4IlI8yhoJOXSguOkbtT9kvc9FGR93LWbKUw=; b=HDjrPuak11nJ0Drk4bYDM4m0V/ZKarMXFWWF2t1+wPUhSxhHEiKYMtF2DoDaWyQPMn huzr1PS9KDxlHdygU3e4+ch5ovQgMrI55gilbwFxPOq60LILmsCzbkxEODQP6iOzqMxh aOgpI0tvrD9owvobmJXEmj0EhmraslH71NCIceYAq6uU7GhYRGII6Usc4tezieZb4MDG cGByIaTrVExK5ZZaMv8HbZdsdnpPA9V9yFfbkIa1y/Xg0hZTE66PHk1aje7wwV4Mr+OJ fxTs3ljXZIjfbuKT42uW1EW9kQbAWzUjUGU5aipqYtUjamBr9g7uEnfv0VilxkUgOzp4 Ux4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733693715; x=1734298515; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=0FT/XI9a4IlI8yhoJOXSguOkbtT9kvc9FGR93LWbKUw=; b=rhxF5R2+McaW7bq56pLL3rWQ/uT8vJXSUxSe5M5/59aEOFVtNtoTW7ptRXBgYZLwCh UCSq2T+4E3079uNWGx24ygeCjC7PgE/Gg0POr51qv/rJ7j4tIuvIrW5dRyYjOYTgI6wC QvHu3obv0gBzYwl45x8196nvdqOLbwTtSvyuDkjrU15zgERvV+1bhGB+Uq6qLN3Dxy2u HR6cLglV2P2Y8jHRsK3FPq2aVdWNk1pFWpbJPmpD8O7vfHGwRbCnU8f7XpOXwbFZnWfg Scl0iEH4iij0JicaKz9On7dtGVLo8RL+daezgsI3Cb/W5nAMuptt4qzAXjLksR81e4h+ d/SQ== X-Forwarded-Encrypted: i=1; AJvYcCVUgJhMPb2qfzjyEVZUiuUiJL6fekCN+JDD0tUwenaOnj2bAcaUdlRMEODEQ1f7au7ltJh9gt6/eA==@kvack.org X-Gm-Message-State: AOJu0YzufUhq5wSN85KaO/0Mj+JAN1pU0cGw95QgANNznWlUGpT/WbQZ 8OpU8bxnC/UZKhKAZ6fUFTztt+oA2K6scIOEwWSFdX4ryzc+iAVBXqvBwB75OhYR1giXuMpTAu/ BRQ7oq9fji57T99YlIVDzfqpwhPk= X-Gm-Gg: ASbGncv2KJheliJjEW92wYM1e0P0QMWRps5VucpdGK3MYBtVfeAtOv9k3pp4dr9JLDg TkqjRDKRVFqiajloxAvan9vtnzHb4+qmDt4WaplJvdB5Ch+ZGkpc9QP5JG55ahlNh X-Google-Smtp-Source: AGHT+IHwAMsuFqDrdyEJ/KJqrCevVJeBoHHGs8woXmM+cTs5EnO5j/yEIYm8u/K9wJdl+o8mXAyyiIFcxhMlc7tMy/4= X-Received: by 2002:a05:6000:1565:b0:385:e95b:bb46 with SMTP id ffacd0b85a97d-3862a913e1bmr6301512f8f.22.1733693714512; Sun, 08 Dec 2024 13:35:14 -0800 (PST) MIME-Version: 1.0 References: <20241206122533.3589947-1-linyunsheng@huawei.com> In-Reply-To: <20241206122533.3589947-1-linyunsheng@huawei.com> From: Alexander Duyck Date: Sun, 8 Dec 2024 13:34:38 -0800 Message-ID: Subject: Re: [PATCH net-next v2 00/10] Replace page_frag with page_frag_cache (Part-2) To: Yunsheng Lin Cc: davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Shuah Khan , Andrew Morton , Linux-MM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: F34E6A0014 X-Stat-Signature: moss35jw9eqqhhr91n34rciy9pnag6s7 X-Rspam-User: X-HE-Tag: 1733693701-677956 X-HE-Meta: U2FsdGVkX18IJjLm6EL8ju2niqIlTEN3CWGFEeziQAqOiQNlI+DnyWsgCHtrYnfr3gRmqZQRI1mr17QSlO66aR6ptY/JfPP2li/HW8zctk1ST1Pu4UgGYY45DhlLaGY1KISqtVqvlx5n6uZJ5yFlkyVDczdU7FV3NJtkzMAVMCCqJBnAmBZ+P0N7/JYA6s9SxMaR5LelFDRxE71OVvunbrN15qdavMofmqAFPr8tvf2vLMVKM+crGWvDAgAzzfYS8BAoTHlDrOpSeVebHcKCJHgvsVfLgBdfgFQr79gNxPwB4ZWIoV742bfuv+QDQ5c/wWCovLHPtestjHlA2314kC9KP0f8nH3waiR/E+lk0QO9fL408oC647iYcKgi+pW35OcaNsJk0a7w+EQ/Bvdt+TW2M1o83xAnu8TPVyb1CXltT3CPYh95Fim+a0mrxY0YPovAEgaeNvGDUXiAfPK8XKJU0NbIS4BGNbA9PKOgSJp/6dMdV5jYyOEM3apjyvw9JS708mxUHnSGDpS7YQ56X6XV919omZTTfvKwmInw1/89nPJS5g1fIBp6amOdh5/oB7wB7UbOM59Qaf7+jt2WTf0rVtJtR+2eZGyV+Og/s9jc6LlfUuK2YJ18cizkqpmCbXRn9F83RuZG9TsBfETDlgmvdzMw0uSBaFmVe/jZovt3dFFfbItT7O/VtNPSGRfxz7fUZDxrfJ9k49acoScdDo2iGvJyolIY5VfuueTbEh6J1eCtGMThodpea+LqXrfvn/YdtJI2MTuolvwkkIFN1pDrucRv2RypGzvLhG8DUlDZV7sop3keQwL0HJSKm2rIChm3ZyysGYBTknXVVgIf222i7Zy8tWIYgmiAEyTYpzGJ2pgDnMsg9+lWelN73UdLyQ6dwhmPtO43yric4SUQRkSei1/Ww6F6aa5MMxPo6Duc0O67Jei31Wjfc3ou45bAQdnM7RZGSIt0sLoM9Ga k6HRusJQ c2usimQUrD/qKyiKliIJXzWffUp5G42uilEj5rDwUU4UVe4oceKucHLyD2k7Qcqv1/mXYQz0skCcz8vpCiortDMv7ZXJ0j6zFaFbmcDBXJyjYSlnVBOQYiGn/ZH3H/n5L3zGu2n7fEiMosaHp63v+aXHYCiK54Tl0+GwC/mgytp5wrmhMdpl8DvyGja+9Fde8qO6z9/oBP8+MVcm+1vBYMFhw2gMwk+vFvfp3NHvBtC3sNVTyS5by1M9jzPx2XVM3lrkPFSmjTTVMtYQykbOYKbgEVDRtboYQCYxH3R4GRkgJLJotHqaRoO4odth/TTGTlsIvVRgZ0G03Xj1yzEFfMetwtTaevJVt5FGbFc1KG1YpgIZJvOhXuUrAKUarPSU46gCxyfuPe3rVzzmxajP+bLxz89UiSsyHEKYtXsg4upozXix8b2TkJCkfb+2n0E7kclErBZLtXan2638= X-Bogosity: Ham, tests=bogofilter, spamicity=0.003810, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Dec 6, 2024 at 4:32=E2=80=AFAM Yunsheng Lin wrote: > > This is part 2 of "Replace page_frag with page_frag_cache", > which introduces the new API and replaces page_frag with > page_frag_cache for sk_page_frag(). > > The part 1 of "Replace page_frag with page_frag_cache" is in > [1]. > > After [2], there are still two implementations for page frag: > > 1. mm/page_alloc.c: net stack seems to be using it in the > rx part with 'struct page_frag_cache' and the main API > being page_frag_alloc_align(). > 2. net/core/sock.c: net stack seems to be using it in the > tx part with 'struct page_frag' and the main API being > skb_page_frag_refill(). > > This patchset tries to unfiy the page frag implementation > by replacing page_frag with page_frag_cache for sk_page_frag() > first. net_high_order_alloc_disable_key for the implementation > in net/core/sock.c doesn't seems matter that much now as pcp > is also supported for high-order pages: > commit 44042b449872 ("mm/page_alloc: allow high-order pages to > be stored on the per-cpu lists") > > As the related change is mostly related to networking, so > targeting the net-next. And will try to replace the rest > of page_frag in the follow patchset. > > After this patchset: > 1. Unify the page frag implementation by taking the best out of > two the existing implementations: we are able to save some space > for the 'page_frag_cache' API user, and avoid 'get_page()' for > the old 'page_frag' API user. > 2. Future bugfix and performance can be done in one place, hence > improving maintainability of page_frag's implementation. > > Performance validation for part2: > 1. Using micro-benchmark ko added in patch 1 to test aligned and > non-aligned API performance impact for the existing users, there > seems to be about 20% performance degradation for refactoring > page_frag to support the new API, which seems to nullify most of > the performance gain in [3] of part1. So if I am understanding correctly then this is showing a 20% performance degradation with this patchset. I would argue that it is significant enough that it would be a blocking factor for this patch set. I would suggest bisecting the patch set to identify where the performance degradation has been added and see what we can do to resolve it, and if nothing else document it in that patch so we can identify the root cause for the slowdown. > 2. Use the below netcat test case, there seems to be some minor > performance gain for replacing 'page_frag' with 'page_frag_cache' > using the new page_frag API after this patchset. > server: taskset -c 32 nc -l -k 1234 > /dev/null > client: perf stat -r 200 -- taskset -c 0 head -c 20G /dev/zero | tasks= et -c 1 nc 127.0.0.1 1234 This test would barely touch the page pool. The fact is most of the overhead for this would likely be things like TCP latency and data copy much more than the page allocation. As such fluctuations here are likely not related to your changes.