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 D0BE9D49231 for ; Mon, 18 Nov 2024 15:11:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1FA676B0092; Mon, 18 Nov 2024 10:11:57 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A9BE6B0099; Mon, 18 Nov 2024 10:11:57 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 072746B009A; Mon, 18 Nov 2024 10:11:57 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id DABB46B0092 for ; Mon, 18 Nov 2024 10:11:56 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8C5DD801E7 for ; Mon, 18 Nov 2024 15:11:56 +0000 (UTC) X-FDA: 82799554320.23.BED8613 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf08.hostedemail.com (Postfix) with ESMTP id DF39316001A for ; Mon, 18 Nov 2024 15:11:20 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZxtknAct; spf=pass (imf08.hostedemail.com: domain of hawk@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=hawk@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731942654; 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=cBOfN40BJsZQSukMm5yGYdG2/q9dry4bTWAzwPuKIJ8=; b=WTfBeX4+bjwDv13c/inTcLD95iPyHpwwRQTiH5oL+v0m5VmUK4HkxeTzY8Ga5zs5Xh5m5F 7Z1vLOJc1MLz36f/LGahu3TvcDpq1/JB2svvVXHiZoDQ1aN9+LiPrrH0rB+7RzO0qK3Qz+ l0vKXj2rs18MuUV8NzHA9Qe81Z/GXjI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731942654; a=rsa-sha256; cv=none; b=wThk/3MLbBrrMbIjbdNYZpOuLq3fkv031N2ASM66xopBMa0pqVszH15yDD3SPG4ncjAfQc 0+bh2tJCpajwdixtf6iCryhCkupSikNIkFRcKprVQioeX+EIouyQkWzFE9bvUrOtv1vzQH CfTh5KsH6Kf9COY7oES/W8RJkomw/Q8= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ZxtknAct; spf=pass (imf08.hostedemail.com: domain of hawk@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=hawk@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id EBED1A4019B; Mon, 18 Nov 2024 15:09:58 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A3C3C4CECC; Mon, 18 Nov 2024 15:11:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1731942712; bh=TExeTFz1ilJ8Wj+pToJnI0x993GlFRsjNQUz/EXz1Rc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ZxtknAct4kAdFJ4YgK/gVZ8EBkvmlYRDhUlFtXfWsmvDYSluSC+6dBtR6BJoS/iXq jpE1jyK3ODuVm6GohUgVQYIxEawnJZk43u9b23IQeeu+weWsYdQHinofwo9xTmDy0d mVvnPeYG5sYec6tYDQgLDl0XPVkb3HjdcHwo3zfqoQpiVa9LNsZQmSY8F62AIQU8Dm 2DWY1xhEtPsb8mw79ZMFMsfZ0dcNHt+Mmaedobd4isTwCbyLDXEIJAJZ8KJr9FKkWD Bk9SH2vvObBvN7Ga3p5BZr2ZknCfAQnLjzglDDInUUsyUryTYrOZLCaymvje+V0kJ3 G+9fYSxKxqw7w== Message-ID: <17a24d69-7bf0-412c-a32a-b25d82bb4159@kernel.org> Date: Mon, 18 Nov 2024 16:11:46 +0100 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: Yunsheng Lin , =?UTF-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= , davem@davemloft.net, kuba@kernel.org, pabeni@redhat.com Cc: zhangkun09@huawei.com, fanghaiqing@huawei.com, liuyonglong@huawei.com, Robin Murphy , Alexander Duyck , IOMMU , Andrew Morton , Eric Dumazet , Ilias Apalodimas , linux-mm@kvack.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, 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> <40c9b515-1284-4c49-bdce-c9eeff5092f9@huawei.com> Content-Language: en-US From: Jesper Dangaard Brouer In-Reply-To: <40c9b515-1284-4c49-bdce-c9eeff5092f9@huawei.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Stat-Signature: utodfd5n199dj8iz5xqhhj1iconixse3 X-Rspam-User: X-Rspamd-Queue-Id: DF39316001A X-Rspamd-Server: rspam02 X-HE-Tag: 1731942680-63780 X-HE-Meta: U2FsdGVkX18AQcA5fKyrxJSVJmUrHh5TNrlzf3O/Rn4mo56anLjsGpbNoaJpg5k4gkfsEKYXeIsvJDvqQu8S12+xmmvNoi8W54cirCpw1DODGbYI3GlRaZPkCspxgBRkQawbeGI5PMITDpvdMB8SsHX1/col/dpH9JocnF+22SLDBP0sDXRpV6sy4ZJfIr6DVGVRingNmCH1SnMbnXeParOK7GeQ+/2/z76o0LdtRPPw3MUQycSELsrTRDyqt7olX7IGbl5ckMhrp4vhPLINAAsRa1YVfIo+MAv2Q62p5GsUqsPw6SyOUsj5p1LsiYGy3k3kffQiyQh34LoLxxI6HOau0N6rEEcKn4QRXFLRaKHCHg+rZuGoogjgzMyppvQwFFLsrmN9UUhYLg4ZZ6TCIYVFySyXAOdHbJbLmgioPgWOyNDD9kvrT9HujnwsV0T+S67b4WcJgDHWohIN2tZXQ6aZST38ALAnphCoTF8Wfd8QRHmLloe+l46eWGg/tYgHrnDzm8fU9M46+X/L4vJDRDLSG1eVWm10IdurPbyiauPt5Cs/r5U1TARdxRBVv2to+MT9u/u5iQ6YaXpS8PPBX7nu3MPZvGEshkQUQwk2Up39aP3l9aGrwIfHEV3HW7KtnIabgEEd3n9pDFqrjuRYSFSfDHjF7niPIDBFMlyCAigt8LfUFxRAgjVuIzNgbkNe1b6jfAAYT6H1E7qP1TnBO0eo6CwKNu/MD9iWcyvYESkar6PnseizeuhBYt23cR1gjG3397tKfxu+buEAC9TU+8EU00rezk3yPXU6ldG08rZlAzxHyw+dQAeUfM6jFPbi/Juaj2SyALNw6eL48HW2Ge+NzO0YOIxOACxcil9AdHuwDmPCW0AKEZXuRc3ETviDuoEODmZ9LZYJfA/Jlu2LsI9PgXPJLmZajt3JHEi8b4TL6OdXVEgn64MQsr5PQwtvV6sOhLvNODPcoKu5fDp Vr1NX0xC LTXZPPMyTg5M6+TwMjAS1Z5vfqH9v5S5hYW5nBbwGlc3XQTJQX2k6Z40TTZzJIrdwUVhOxBne6wjx+gNua+mjwM1cAmGqzKw0D9ELdiOV+gPXin+sXKJUJeFVqwG5NZVDZ53oIyIVsqC0JoQYAGu7X6RI9JYDILLe98p9k3RPsemF4bSRZnsenkayriheot+xQGE+l9OnvBp9SKu15CMHR7AuoVEHwrYgeFii/rOzrls6UEVCDPpppWYTH8ChtCdiWyjexP7C7iTDMe70Gp5zI72T6shplG06kupc2VYwf++ugjN4Ctb6zBivcGnBAiucZ0AsqrruPeIPNea7i5WEVZq5WqDq7X+HIG3apoS/6sb0XMrZDVNUIa3UJ97T52B7iscuhkoRFz75+XjyCkThbHn9AL03YYd8JeQJ2bE76j+AFslz5tBo+jvrlaXAYsUS5V86ihtxQSNCV4Xg7JYb1OJrJw== 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 18/11/2024 10.08, Yunsheng Lin wrote: > On 2024/11/12 22:19, Jesper Dangaard Brouer wrote: >>> >>> 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. >>> >> >> Yes, please.  Can Alex Duyck or MM-experts point me at some code walking >> entire system page table? >> >> Then I'll write some kernel code (maybe module) that I can benchmark how >> long it takes on my machine with 384GiB. I do like Alex'es suggestion, >> but I want to assess the overhead of doing this on modern hardware. >> > > After looking more closely into MM subsystem, it seems there is some existing > pattern or API to walk the entire pages from the buddy allocator subsystem, > see the kmemleak_scan() in mm/kmemleak.c: > https://elixir.bootlin.com/linux/v6.12/source/mm/kmemleak.c#L1680 > > I used that to walk the pages in a arm64 system with over 300GB memory, > it took about 1.3 sec to do the walking, which seems acceptable? Yes, that seems acceptable to me. I'll also do a test on one of my 384 GB systems. - It took approx 0.391661 seconds. I just deref page->pp_magic and counted the pages, not many page were in-use (page_count(page) > 0) as machine has just been rebooted into this kernel: - pages=100592572 in-use:2079607 --Jesper