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 C6B73D32D9E for ; Tue, 12 Nov 2024 12:23:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 302FF6B00DC; Tue, 12 Nov 2024 07:23:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 28C3E6B00E3; Tue, 12 Nov 2024 07:23:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0B7256B00E1; Tue, 12 Nov 2024 07:23:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id DEC4F6B00D5 for ; Tue, 12 Nov 2024 07:23:08 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 95EDFA1867 for ; Tue, 12 Nov 2024 12:23:08 +0000 (UTC) X-FDA: 82777355556.01.24E11F5 Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf08.hostedemail.com (Postfix) with ESMTP id 8048D160029 for ; Tue, 12 Nov 2024 12:22:37 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf08.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.190 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=1731414011; 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=YHNDINXnPd/UVsMAhLb9fxha+4tBwQyCSKh5co2LioY=; b=72scY3HoALeQxr47DRiv57n2S7VUkOgv9tj3iSJ1WJjqRnIY0RlsJsThMj8ZrYdNRUeIeJ Yl+V5FbxWUCxaDbHMJjc2ab2UI9caxWI94YWURXP128BgHAc2cFnRr4QuRFAGEQsCOBZRa v0ib20baVVzMUJapzT681GzmAW0cQzA= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf08.hostedemail.com: domain of linyunsheng@huawei.com designates 45.249.212.190 as permitted sender) smtp.mailfrom=linyunsheng@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731414011; a=rsa-sha256; cv=none; b=Dy47YqLGICt1wJK5cUxQGenTxCkuOIh4VVHb0cJ8YH0AKQqPcaNLC8t2qOj2OxqdKHnZuV SNEKZD8di/S0ue6Jqd3vFJPz6tjuNR6mCZdM9WMrzPFbs7GTEP1rFcAZOffbcnPdn8hnti C4dBN1mb97EKpm26XBXoHp0KteYQVZ8= Received: from mail.maildlp.com (unknown [172.19.163.44]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4Xnls418Fyz20t4f; Tue, 12 Nov 2024 20:21:44 +0800 (CST) Received: from dggpemf200006.china.huawei.com (unknown [7.185.36.61]) by mail.maildlp.com (Postfix) with ESMTPS id A8FA914011D; Tue, 12 Nov 2024 20:22:57 +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, 12 Nov 2024 20:22:57 +0800 Message-ID: Date: Tue, 12 Nov 2024 20:22:57 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next v3 3/3] page_pool: fix IOMMU crash when driver has already unbound To: =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , Jesper Dangaard Brouer , , , CC: , , , Robin Murphy , Alexander Duyck , IOMMU , Andrew Morton , Eric Dumazet , Ilias Apalodimas , , , , kernel-team References: <20241022032214.3915232-1-linyunsheng@huawei.com> <20241022032214.3915232-4-linyunsheng@huawei.com> <113c9835-f170-46cf-92ba-df4ca5dfab3d@huawei.com> <878qudftsn.fsf@toke.dk> <87r084e8lc.fsf@toke.dk> <0c146fb8-4c95-4832-941f-dfc3a465cf91@kernel.org> <204272e7-82c3-4437-bb0d-2c3237275d1f@huawei.com> <4564c77b-a54d-4307-b043-d08e314c4c5f@huawei.com> <87ldxp4n9v.fsf@toke.dk> Content-Language: en-US From: Yunsheng Lin In-Reply-To: <87ldxp4n9v.fsf@toke.dk> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.120.129] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemf200006.china.huawei.com (7.185.36.61) X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 8048D160029 X-Stat-Signature: k61opzpwwfjiw5gney7ef73p8u5kmsx5 X-Rspam-User: X-HE-Tag: 1731414157-454231 X-HE-Meta: U2FsdGVkX1+zX8Ea9o21EeDZ/P25iX60aPzLN4rFI0C1t3anKi+C+v41OrV8rukAe1R6Tj6/T1doQtW/3xvMDixz3ZVg/UgT5Xgy/HVrHhBio72W3gMuuIbbz529Ldv6IgSFSuwhdTaQklYyK8LdCCuvLDJDxUdY1eK0pIDI9LjRAt6zfb099NXz5FNRb5rIQrhFDOq9fH18RgIGSjXnwHSN6Tr4fTz8cJ6ztDjqb7QQPev8C6RxyTWI/kArDBBAgH5LOq0ciq07GBEs8ZASL1LCzFnZ4rAqXoBCmvwQ4cSXSn45YAwlWppo8nZlL0A1KMlLS6tydVzJPvZV/8YGRwhs+8kfBlGlxaFraM5vXydO5hH87FjbJkib39GeBh7jm90LW4OKvflDTS1w2d8fL1mVaSlRSR/d1ANgu6gmBf8alwOC7X+X2ym8jHOXO12b4MpnS65uEC4zOUm/heH81mllEMgXCubsDcYHTWOrVIj1Z9rPTy5m62HUSH7A39pUWnj6az7S7yCHOHPlCbvz6y3/7ZsCnZ+YOHhgsoZIhV8uL7xp+aiWmJE4Uqr3xqkGzSr0+Fqi0OIBjpZ6EfbI3KxUPnll5hTltlpB5LWjtttU8lE4jO4iNtZIYnfqNy9WlAEiGVW2dw+eCKkQ4B/fqjtAFkCICLdNCQSyYP7Ai0HamC6u4WDTI1WAJEsNoKOUrqHYz9BSIxVN0ARvwyB6OeRnj4gQMTNmZmcOaHdpq6JqMA1wX2t+iwao00U0FaHsByrXCUp8gsugQDMTJdKI616dthZlEJpdmc0htvWFJeMI6aVygqGRUyUmQ68gv4fvc3eavHts/qriANvx6RK8qFmVXbq5mhF2W6rEDq8qmnVvL7qvUW0VHCadooh09CuqaCuYYJwuKUidzZIVJe3zeva0aKEGdhr4d30tgw4h9ZiyshF7UNXQ03qM+ms6gXIdT92fU51aPmO6kBYr49O f93oC7uj lwm5nhmp6gCtFarPPmdq9WexsuI294HjsZeqy4VigoV4Dqntp5i5NunParLrSJ9oyyq3mGQ3gmDbuLzawdLJlQEU7i3oKWjRjGf+lB8TcjfDiGn+Wq0+e+58/HsGI/KLG6p3NdK9GLNtCoxnnUHI4Y3lhPOdzk3uRccD+Sa+UR1o0P/n7Mya879BmAoaOtbne9eQm+9rEA0S50UNb4oC4gjWz791mv1BRtonHoDYRdhLoLK7II7QLs4KmbaIPeTZAIdtgg2xYGOma+eYbhXARm1b0mZZwNhdYuJiidIF1TC3uW/j5dSugKYXYccKZ70M3SIlJ 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 2024/11/12 2:51, Toke Høiland-Jørgensen wrote: ... >> >> Is there any other suggestion/concern about how to fix the problem here? >> >> From the previous discussion, it seems the main concern about tracking the >> inflight pages is about how many inflight pages it is needed. > > Yeah, my hardest objection was against putting a hard limit on the > number of outstanding pages. > >> If there is no other suggestion/concern , it seems the above concern might be >> addressed by using pre-allocated memory to satisfy the mostly used case, and >> use the dynamically allocated memory if/when necessary. > > For this, my biggest concern would be performance. > > In general, doing extra work in rarely used code paths (such as device > teardown) is much preferred to adding extra tracking in the fast path. > Which would be an argument for Alexander's suggestion of just scanning > the entire system page table to find pages to unmap. Don't know enough > about mm system internals to have an opinion on whether this is > feasible, though. Yes, there seems to be many MM system internals, like the CONFIG_SPARSEMEM* config, memory offline/online and other MM specific optimization that it is hard to tell it is feasible. It would be good if MM experts can clarify on this. > > In any case, we'll need some numbers to really judge the overhead in > practice. So benchmarking would be the logical next step in any case :) Using POC code show that using the dynamic memory allocation does not seems to be adding much overhead than the pre-allocated memory allocation in this patch, the overhead is about 10~20ns, which seems to be similar to the overhead of added overhead in the patch. > > -Toke > >