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 1CAD4C28B30 for ; Tue, 11 Mar 2025 13:26:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 53C8E28000B; Tue, 11 Mar 2025 09:26:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4EB86280001; Tue, 11 Mar 2025 09:26:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 38D1628000B; Tue, 11 Mar 2025 09:26:37 -0400 (EDT) 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 16423280001 for ; Tue, 11 Mar 2025 09:26:37 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id F41001CD1CF for ; Tue, 11 Mar 2025 13:26:37 +0000 (UTC) X-FDA: 83209344834.16.23803E6 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf24.hostedemail.com (Postfix) with ESMTP id 9FAC1180009 for ; Tue, 11 Mar 2025 13:26:31 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="PS9I7E/n"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf24.hostedemail.com: domain of toke@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=toke@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741699591; a=rsa-sha256; cv=none; b=8ICgfNruhMwvTTRyxyPvMUAj8qJtfrPvHay9nYSlaM6+Qp1ypQN+LSpNF33Os6YBBn7MVH 28no2D+rd+XvbWHBWGrEyuyyHjp09mxpl/JV+bgBjqWt18mOhMGmG8vhob8FEj+yYrNxYo zmz74qKqarJicSKlVL3m8eaGgll+V2Q= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="PS9I7E/n"; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf24.hostedemail.com: domain of toke@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=toke@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741699591; 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=jZp3TsAydg/7pFakiI6TW85wSippRGwKXlTwcNBIPos=; b=yuBBy96s+ddaHDFX1Jqd/oeMUilGbZpdSC7OH5gIsabTBxchQnBnbBYYvMxPDuaTMTj+tZ VWjyM9YmHyevZpDJmhdyS0XjJvh1GvYHmdXLLo2j8+TEgGZ35J8glriYCY0XsSys53Wtkm d1e/lFzpmvMIuXpcMr/dfs1ZbaJqtsQ= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1741699590; h=from:from: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=jZp3TsAydg/7pFakiI6TW85wSippRGwKXlTwcNBIPos=; b=PS9I7E/nlSPrys8ngwkmmJ48scWB5sGVYIdu1T+4vPVUy00le4XBDsUIBQncoRgHj3Oo1z wruWW3yzSlgB97UQ0zosDutze3N1iT4O0W6dzADEAWT6NWveVWHTusUtXCeYARq2wf3M9U 4PAIvqOBgQY5No2MBcTunN0XTfk1nvM= Received: from mail-lf1-f69.google.com (mail-lf1-f69.google.com [209.85.167.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-655-0PE1sOPGNXS69zyVPzTSoQ-1; Tue, 11 Mar 2025 09:26:29 -0400 X-MC-Unique: 0PE1sOPGNXS69zyVPzTSoQ-1 X-Mimecast-MFC-AGG-ID: 0PE1sOPGNXS69zyVPzTSoQ_1741699588 Received: by mail-lf1-f69.google.com with SMTP id 2adb3069b0e04-549999af7bfso1626735e87.0 for ; Tue, 11 Mar 2025 06:26:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741699587; x=1742304387; h=content-transfer-encoding:mime-version:message-id:date:references :in-reply-to:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=jZp3TsAydg/7pFakiI6TW85wSippRGwKXlTwcNBIPos=; b=Wt3L7Su5XmzDnaL5cyNDGgDJvRjLZMUx5KD+NJpI+7K8FHtL4KtquiZY/ENPFn7CqW e7urvPQVyFzo3o0U+IjVIrRrLBXt/eECvpStGotPLgu9a9FvzNYKZp44PBEsIXleOVCM cfqXVovPtt6rRXE56dKO67dho0BqVsLzXKvqTuwt2Yj4dqnrmruX84VPse82EY0n/Hkp hGHXsxYXwWAvzoNtN917bSLdeipHfEfPaitOghVpSgQPh5KImDfKHx+9wQ1XDEGlPx71 m0JP/YNPxD42OpAAoMTCpiSimrIZD3wEOs4zUgcfamvaHza0CcmqriAK1HTKJnaNK+kv TREA== X-Forwarded-Encrypted: i=1; AJvYcCU0jg0dTKuEc7m4HhDmkRhS0ucgZOXVU/XomadKwYup8GZ5J2B2YNN41mmsb/gagRSqeNcxCIphOA==@kvack.org X-Gm-Message-State: AOJu0YzblAAS/AEKKICEpTbAd1NcThdZNaReQBZ4nfxrm89fRSBlX1kA eb6shbSX1H5WcnJlWyr/+DjDKAzPNuJFHzCmUj7rwooQKmu6B+LnhtPNL5N429KcrXQt/GjUNdI PnwcZ0ndKnDk6KqDKLbw0tf2Fn8PpXHDtdYjdTEiZZLkVd1++ X-Gm-Gg: ASbGncupYY72lRXb94Wzn7aKNdQ/ZFcAT9WoXQyFwgLMiZZoBtXpjxucYf/Nd9Tb4Vj Hw2mRchG106piZnLUPgesnrtrCrDS1d9qSS4a8GZdWLDN7jvX9I8IW6g8zXpVVA8iFoZQd/qYmH 97l7tBfGDnPKKmQVKXO2wfAF7Lgt3o9ex+9Qt/9nMENyis5vz/JcDsmWVvmjf9fWGt711Ob9v33 55WKKjdLtAQa0qn88RioyVcVYAv4fWvunRCPEPY7c6LbDxrs+3BHBV3QgteUdUIp9bb5355eGM7 tyzehNcy4wrM X-Received: by 2002:a05:6512:68d:b0:549:7145:5d24 with SMTP id 2adb3069b0e04-549910b7c48mr5870437e87.46.1741699587437; Tue, 11 Mar 2025 06:26:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHJbASutO79ZzDgdNEoOXQ+y1j4qBwd9k66DRAoi/s3im9A+vgvleJ7lXueiO1Jeoxhngqv4Q== X-Received: by 2002:a05:6512:68d:b0:549:7145:5d24 with SMTP id 2adb3069b0e04-549910b7c48mr5870419e87.46.1741699586962; Tue, 11 Mar 2025 06:26:26 -0700 (PDT) Received: from alrua-x1.borgediget.toke.dk ([2a0c:4d80:42:443::2]) by smtp.gmail.com with ESMTPSA id 2adb3069b0e04-5498b0bd0absm1816132e87.157.2025.03.11.06.26.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Mar 2025 06:26:25 -0700 (PDT) Received: by alrua-x1.borgediget.toke.dk (Postfix, from userid 1000) id 4552A18FA59D; Tue, 11 Mar 2025 14:26:23 +0100 (CET) From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Yunsheng Lin , 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 , linux-mm@kvack.org, netdev@vger.kernel.org Subject: Re: [RFC PATCH net-next] page_pool: Track DMA-mapped pages and unmap them when destroying the pool In-Reply-To: <136f1d94-2cdd-43f6-a195-b87c55df2110@huawei.com> References: <20250308145500.14046-1-toke@redhat.com> <87cyepxn7n.fsf@toke.dk> <2c363f6a-f9e4-4dd2-941d-db446c501885@huawei.com> <875xkgykmi.fsf@toke.dk> <136f1d94-2cdd-43f6-a195-b87c55df2110@huawei.com> X-Clacks-Overhead: GNU Terry Pratchett Date: Tue, 11 Mar 2025 14:26:23 +0100 Message-ID: <87wmcvitq8.fsf@toke.dk> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: yWFN5ErdVLfyKPwv6aYzs3CXX5h-d5pSh-p8401xu1o_1741699588 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9FAC1180009 X-Stat-Signature: b3mn6sihyojuda1crb3oew7ewgo9wu7h X-Rspamd-Server: rspam02 X-Rspam-User: X-HE-Tag: 1741699591-402877 X-HE-Meta: U2FsdGVkX18OUQbtkd60tMfX8e0Y1Pnaf4TQb4uuByvNq6D7jBDJpp6rw9L+Pi4KQ8kdYGSLjDGy5iJZjn6gBVik6Pn9pnVBXZVu6mr4/cdTbQtPpNrwE9natIHkBIV5t7SEZZ0EpHrKPLXE9tW+Sy4NUmawCQAdcnFRvGwtjeVky6KrZeiDzJQSxwiz9KPHyFg4XdtvKDtbP8pvzjDMCEAkG1adBJwd4Thi4Vj/LyacWVlvy4PhrM7AyPmF7o814GUdR8yXJVVVwpOrE61Cx3Ih/DI9i1C8sXpyYE5XEtGoYfRbb4ewwPE15AFcFAR949SzKQO8CCeNrdmOaNLWwZSGyGtrgupgxKMEzffamHW6NRd9jkr3V4Zjcmak/kFrYo2FanOCqC7TLxZolFVkJOu+b/m0uM1lW5m2ko9z6LPzHUT7UFRfXNMpl5A6ZlzxG9ckNTWSQxYXmXgqn+kKqceZZQhPLU0BCVbtUCSnAcZS/COLXG3MOVHfuDHwYMu2DdgaRmlFKmpgs9Pua/XpON5xe97wYBxtVt2YsStGD8vaKIrjkXsUNxmEvOKu0JPYIIwYMynj1RXG54fPuLuiow11J7NPxjNq5DYmctlrWifCQ5JItdLOcZX2jIggfiXEOsZJzY9YQZmnDwzbcHhZW+hqjLETguafJZ7+Td4onf6T5HrKNovqfQ+LSi2WYiZbTJ3dsJMEc4amlhxgIqoxbHIGY6wWEvSETzngCimG/AtDSYEdR0DpHXwuvuBdsgSjjUjmwyhdXULFm2T9XlHSjOJLX7n6nEpeb+FuvBkYut9H8jJb7Xc2YCGzo6aq8LsIOtqDdZRvtb2igWAfvicSJJgn6hrgKQ/3lHIouR1fpPOFQ0YqTHZiAiBfZEbtCzeQNndfxv0u0GU8L4ekylzkyL36Z5ZPAI951CwATuN29mc1+Ir9BahspMYWMXMX8Amfu4y/F3+GZtuVHQ+PXc7 zc66OH07 B8YrcsRSlsiEQ4MHRYn4KdMq4AJVR1A4iqmn2biqM8WqplIo2En/GyCegdsrobuZJEmaQj/SjcWS/uGnP5ZAqfs1M6arxYbGhp7/tFq7VkNMKmxt2HjTtjh1ZBqk5ro1Ogid2xdZcOkc8wo4I69UVEEW7DyHKHi6V1d9AaKUohkiSbBGQvbnSRmwvJs9ozPp0vZlWzmbxCV1NFY9h3ZoIcbYDSZzXPULPBEUXcGDUlZB8VHfdw6RQlYu/+kwiu4H1pOi+xzNBGyCs7b0l/yoW7yAeuCntLYXKfQhkXD28csElsSKarPaQebr3A2IAHsQAwlynW7nf7e8cCD/xCmK8nLsUn4FN5QUHbMC8DZh37rIXvoxJ82AnkI99AD1A/p5rAM/2AkzJswNy6ufPGjHnCFwlFgW87Z9ZaJIYYMlmTNlqOb19syTRVK4/9XxULsghQeZwgHWZ3QvCOC3fpOKt6V6WVXHWgmx6cAM5p8P+DC/tMg8JjRw3WqhueguuBoqAdAd9 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000983, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Yunsheng Lin writes: > On 2025/3/10 23:24, Toke H=C3=B8iland-J=C3=B8rgensen wrote: > >>> >>> I guess that is one of the disadvantages that an advanced struct like >>> Xarray is used:( >>=20 >> 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. Yes, which encapsulates the complexity into a shared abstraction that is widely used in the kernel, so it does not add new complexity to the kernel as a whole. Whereas your series adds a whole bunch of new complexity to the kernel in the form of a new slab allocator. > 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. I don't think it can. But sure, there can be other ways around this. FWIW, I don't think your idea of allocating page_pool_items to use as an indirection is totally crazy, but all the complexity around it (the custom slab allocator etc) is way too much. And if we can avoid the item indirection that is obviously better. > 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. Yup, basically. > 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. Right, and my main point is that the complexity of this is not worth it :) >> 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. Yup, did think about using the lower bits to distinguish if it does turn out that we can't avoid an indirection. See above; it's not actually the page_pool_item concept that is my main issue with your series. -Toke