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 3306EC282EC for ; Tue, 11 Mar 2025 15:12:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6C10F280002; Tue, 11 Mar 2025 11:12:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 671F3280001; Tue, 11 Mar 2025 11:12:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 53A78280002; Tue, 11 Mar 2025 11:12:23 -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 E6BE7280001 for ; Tue, 11 Mar 2025 11:12:22 -0400 (EDT) Received: from smtpin21.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 744781C7393 for ; Tue, 11 Mar 2025 15:12:23 +0000 (UTC) X-FDA: 83209611366.21.2D8D8E7 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf03.hostedemail.com (Postfix) with ESMTP id 87FCD20006 for ; Tue, 11 Mar 2025 15:12:21 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=toa2+2Rt; dmarc=none; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741705941; 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=vmHrb0b24qlyWrlqCdDj4UGq4nq9/s6Su9V1a9JlSO4=; b=fsHXhw//LEJzViPukwuJXjhLAtJHWIOmepr+uao+ao4H6Aj7zD2jdouWaFSrnmcfFDJBPs 1Zm7FuL+moe1kq+MhO2w5voQm+2aryF0Zm1I0r0pUGw9nYsnL6+eaP7d+JZ943jzJFDoXa I8SIsJB1Rd4+8dogh4CN2mCH7orb/bo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741705941; a=rsa-sha256; cv=none; b=SDE8kPuIjnB0r2OlKTVptQUWqxx6e5HA3jV+zuiqQvINWWMK4RWdJB6s4IFqoLWOHY4l8e mD61qcLNYFUIFVRuauD4L3HDyRyNhEk62sQerty2OHfgwMgS9equKXbQEDqEsBCzlqrIp/ txpAXlkhg83uzL1NfG3fZZ4iJpQBuO8= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=toa2+2Rt; dmarc=none; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vmHrb0b24qlyWrlqCdDj4UGq4nq9/s6Su9V1a9JlSO4=; b=toa2+2RttopItVIdFS/UqMj7dZ y2J7Xr77rRqURBhWbPDwlckYlaxzLUtpCiGA1bre9o/XBJGGAUFxlMji+ppmLd7fFHo1jTetTnWtv ye74EjPgi7lGi2Zm+XvONJoGzxxTH2YhEDlUnGiCTg3i0RWlx77/HSt5t1lJmoNoAZBz91Y+3eGEZ dfWWnEGCCm1GRKPUdrttP5YJFuUs/ZQoa3UYT7vlgVNLcE7U/g1A0KwacrL/5t90TN92j0YC470h1 24w0a24jK9qGBqA76KOZnIcNoWrRkwsaBAIqp7BcecKskEUEZbrFfLVWKbk4iIeIv/Tu7BUOJIito +qgGO8KQ==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1ts1GJ-00000001vOb-27i7; Tue, 11 Mar 2025 15:11:21 +0000 Date: Tue, 11 Mar 2025 15:11:19 +0000 From: Matthew Wilcox To: Yunsheng Lin Cc: Toke =?iso-8859-1?Q?H=F8iland-J=F8rgensen?= , Yunsheng Lin , Andrew Morton , Jesper Dangaard Brouer , Ilias Apalodimas , "David S. Miller" , 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 Message-ID: References: <20250308145500.14046-1-toke@redhat.com> <87cyepxn7n.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: 1hbxefmr71p15ur69gsrdbat4x7yhjne X-Rspamd-Server: rspam05 X-Rspam-User: X-Rspamd-Queue-Id: 87FCD20006 X-HE-Tag: 1741705940-278949 X-HE-Meta: U2FsdGVkX19NGUDizbyHSikgktu6tQdT5H7htBZXimuhbdmyiZI2MPMop37FikOev6JWqWi5jG4jx/GkTH6l5t7rkFRr7RwxwGrjjMpVSF4KQfbEW34LD9JlBd0ESjyLNqvv5mgg3hXGC5H61sch5hhRInYfemmNzXcaKedniHxFOnmj054Wd0pZV27OgYiUrVjVjpK2DZwmPESKUIRBEn3jRX565IaclIA4u7biZpM+r3gzJI/6vn25Nh2AxdWle/FBisjZUlVoYbgxoT8e+bDhVYeCUJj5wzDrjPZCnYNS64j9l4VVkh8cmDOf/r7O8u21953dMKHK/4IXUv1inIDqYkWLoX/04f8iiFxv5vvPVOUx8RnQF5tp/lxaG2dj5k0XnWA6HvHkzBfAT0G4itytpGCuAvDccsv4e/HOfDL0YN6Vb2eb9a+WYxh0Y+0jsYE16WU8dckxjASuF5208VNMilwzSlb6NtnZIstaZ6xkQOzxcm90HlDubaUUTdottraks+autS6xkMh5e1imEeVEPRoWJVr/BEeamDg4Z9B+Wzeakz4RhxSvaFYsSkmeWH23jCOXXUQRwjLe2WdAr0L9rY9BUhWqR5LdFvte+LtYYzDAELQMEovobb9qkkgH56V6W6EnyL68bOlMVbjbxTQmN6rgjUGoldYNA1sl6ZoGbDBEBx7GRi6l7GmcyO63VRIgd/r9gBeHaqPbm+TuoCJPuSeDTZcDy54V7AmSe2mHwZ65yuOrAP1JP3/pGO8rFsF52uOx3FCLcy8d8mV0aOTnkwSBsZw9g0SE9uTsa5ZyBeepl1Yl0liWwH3ksAh8tDNhZOkhkkgLoEfBD0pLcqSM7sMzmWbiwkKGe6q2amGxYaxhYNn5O848L3pHbLVbM7TxLjpyb+hgbQm15YvcbU+4J9RMqAFKtICWjnjaVAswQ3gjsIh5oeZh7KDkZSp0uU2OLLXzKcHghH3Mgnq XO/yX6P3 2dCrIWqdkwjoNRorRt1kw62UMuZvSK81MjzpD6n8ZXncZvhCcJ60r8/t1dn52fI6IECv9U+yw9SjwVnp5+LiRklsNffGy8p7npU0WhjtCkeBHaesYscQKlikVuiFXVOseJjx1eepGKhNi09rhXkOtDqScX4HTSr27O1FkjL5J+Tch+lQdkP9qFZWf74qu21cEj6wMlfDRfW7J3gMnHBcsrJ1XJSRR97ZfxzfUGx5O4z7FQg4ZIYCBo9iXbkPuH/dW21CGBX9xtyRIL/0vg0RsYGML+w== 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 Tue, Mar 11, 2025 at 08:25:25PM +0800, Yunsheng Lin wrote: > > struct page { > > unsigned long flags; > > unsigned long memdesc; > > It seems there may be memory behind the above 'memdesc' with different size > and layout for different subsystem? Yes. > I am not sure if I understand the case of the same page might be handle in > two subsystems concurrently or a page is allocated in one subsystem and > then passed to be handled in other subsystem, for examlpe: > page_pool owned page is mmap'ed into user space through tcp zero copy, > see tcp_zerocopy_vm_insert_batch(), it seems the same page is handled in > both networking/page_pool and vm subsystem? It's not that arbitrary. I mean, you could read all the documentation I've written about this concept, listen to the talks I've given. But sure, you're a special fucking snowflake and deserve your own unique explanation.