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 C577DC282EC for ; Tue, 11 Mar 2025 12:19:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7ADE3280003; Tue, 11 Mar 2025 08:19:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 75DB8280001; Tue, 11 Mar 2025 08:19:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 64D9B280003; Tue, 11 Mar 2025 08:19:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 468E1280001 for ; Tue, 11 Mar 2025 08:19:15 -0400 (EDT) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 9C3ED57F3C for ; Tue, 11 Mar 2025 12:19:16 +0000 (UTC) X-FDA: 83209175112.23.5B14780 Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by imf11.hostedemail.com (Postfix) with ESMTP id 3D95540012 for ; Tue, 11 Mar 2025 12:19:13 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741695554; 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; bh=9cAwXlnHURtPHFH2HFi9IWxM2Q7OlcKYcWSIyb4c6dQ=; b=xyS/3dy08o0uv/0aKrcIJ5l4S4BlKHIU7VUqnnf00JDHAPdsIHjHIPoIfjko2Yysq6L173 YZFcLX1KtKE92zMYVR//ZKgKNT6dJVK0KcU5qksaUTa7VLr11mE2hHk9iRDogV11ZbeHF7 lI95uq+EjksAnQMcDz/B2chvcKeHMjI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf11.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.187 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741695554; a=rsa-sha256; cv=none; b=JODrgQh729IW9buDNHrdMhFI2KgCtVKSoMC4qMW4TgIBFW614y67PpJoAe6JXmOmRge++c cWaclPa+dIwgZAdnTHjaI1KPkI50ZdvTlNORB1V7k2Z1C8pe0ibzkNI4FSF3PCLaCoFd5G fAb/W9qQvjMJHffbDtkMiAJ9tCInlfc= Received: from mail.maildlp.com (unknown [172.19.163.48]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4ZBt963VztzyRrq; Tue, 11 Mar 2025 20:19:06 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id E2738180080; Tue, 11 Mar 2025 20:19:09 +0800 (CST) Received: from [10.67.120.129] (10.67.120.129) by dggpemf200006.china.huawei.com (7.185.36.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 11 Mar 2025 20:19:07 +0800 Message-ID: <136f1d94-2cdd-43f6-a195-b87c55df2110@huawei.com> Date: Tue, 11 Mar 2025 20:19:06 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH net-next] page_pool: Track DMA-mapped pages and unmap them when destroying the pool To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Yunsheng Lin , Andrew Morton , Jesper Dangaard Brouer , Ilias Apalodimas , "David S. Miller" CC: Yonglong Liu , Mina Almasry , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , , References: <20250308145500.14046-1-toke@redhat.com> <87cyepxn7n.fsf@toke.dk> <2c363f6a-f9e4-4dd2-941d-db446c501885@huawei.com> <875xkgykmi.fsf@toke.dk> Content-Language: en-US From: Yunsheng Lin In-Reply-To: <875xkgykmi.fsf@toke.dk> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems705-chm.china.huawei.com (10.3.19.182) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 3D95540012 X-Stat-Signature: d48zx5mcxktfs5rae14c3j1jatqcb9rm X-Rspam-User: X-HE-Tag: 1741695553-742201 X-HE-Meta: U2FsdGVkX1+l2S/9HWHKW8Zz5CF35ry7TTKHRJYT7vwvryeuXM2F65wsrsoRmKmwYTpU9EbkXFjmcwgCDrY6fPWzc5dL7/EPZOQ7mAqzk65M0Jh5hhPXeWfZi344S3jGMDEpIEA/MaeWQdNkJyzoNseSv7mYQ4rDE3wPZNeVQO8iny9KDs0QWZJwsJ734JOuDeDQ4Kj1Mz9+ZxSjlQINpX0xwsptk9alHrd3sNu6X2RBY6nRiUiuGn08apkWMPROioFdmbnndLWR1snL8XrgJtnbRYQRZbkzUyoHRqCf7qR0kxjJqYZ0Ext2ddnfQbkF+WfG7zOsndTG83qmRIgZs2egsToEDlUsQS93ztk14RsXKbYuPumzDLThpxvA3ZY/ZwuZ0Dvr4xs15G1V0Z9WMFT/LnKdh/4Xt25vQ9ItN4T6oEeDyFx1dRuGhjxXh+t/oTMf7qLZXd2DxhcF3RG8bOGjTzRxoP17PLD92v7aNQKgmr4IcvpN/lAUa7I8XsUFeXcv3UXJ2du3XXegX6xHftSBHErGukk1Zs19jRdUWrGqzBixSrFgnxCzrgTQehTXlEEJmhiS9EQrfAWXzy5jRRIyFxQv6m5eCnoac4ADdYVXnQIlaB0+IkgY6Iq/I/+BuSD/W7usqjBji8eESBxFbey/f2TWCC+Czce6Z7IbJ8Y0rQAjk/VPvtDWPozJwx4XSZKJa6rt+natpdMuVvglM4QNjJM268bHHFi3zEK4GKuKBXZX/TJ96WrrBeTq/DvwTOMWbztqezmrSdyk/FbECPMdXbxrZoq2stUJPtGsKaBSq01qXfFJVMWHHF4WBGtGR5Wh5yJknJrJIofV+407SBs/FJqx1shebBThKmo1PHBCxJWj8Zs2RyfpqqzEGRqi74xlmXjFUIUb36Ptt1SgHewenTCjDy8u3ecEwXKg0K2NKBI7kF2YEDivB4CpzLWgeQ8Ee+9cKrn7x2bcGo3 nd2uVdLO JEAj11hIqJap1X0cqKpozxuNJ5My6akbzsO6wjITqldXfd8RJFNfJfskAJ3LMFXgtyB8d4YvHNsg8d8b4sjR4m7gkLTGT2JMOu+TJ/8NJ0sCMXkIY5BptdupBnHg+nVPe3zjeCWdYsCQp3m8ETo3wZEc188NU5nZ1vDWy5mnQoWaJwVNjoJNRK/d252sH+OkfnnKU85fnywtRro7TeuyxPx1YBa3meUdkQWrXTzFs3buMENcj8Hn+IgF12Q== 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: List-Subscribe: List-Unsubscribe: On 2025/3/10 23:24, Toke Høiland-Jørgensen wrote: >> >> I guess that is one of the disadvantages that an advanced struct like >> Xarray is used:( > > Sure, there will be some overhead from using xarray, but I think the > simplicity makes up for it; especially since we can limit this to the As my understanding, it is more complicated, it is just that complexity is hidden before xarray now. Even if there is no space in 'struct page' to store the id, the 'struct page' pointer itself can be used as id if the xarray can use pointer as id. But it might mean the memory utilization might not be as efficient as it should be, and performance hurts too if there is more memory to be allocated and freed. It seems it is just a matter of choices between using tailor-made page_pool specific optimization and using some generic advanced struct like xarray. I chose the tailor-made one because it ensure least overhead as much as possibe from performance and memory utilization perspective, for example, the 'single producer, multiple consumer' guarantee offered by NAPI context can avoid some lock and atomic operation. > cases where it's absolutely needed. The above can also be done for using page_pool_item too as the lower 2 bits can be used to indicate the pointer in 'struct page' is 'page_pool_item' or 'page_pool', I just don't think it is necessary yet as it might add more checking in the fast path. > > -Toke > >