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 6BB72C02194 for ; Tue, 4 Feb 2025 14:30:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7BC06B0085; Tue, 4 Feb 2025 09:30:04 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A2BD16B0088; Tue, 4 Feb 2025 09:30:04 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F3746B0089; Tue, 4 Feb 2025 09:30:04 -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 72C266B0085 for ; Tue, 4 Feb 2025 09:30:04 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 03A71A0A8E for ; Tue, 4 Feb 2025 14:30:03 +0000 (UTC) X-FDA: 83082496728.01.D682214 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.17]) by imf10.hostedemail.com (Postfix) with ESMTP id CAC21C0008 for ; Tue, 4 Feb 2025 14:29:58 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MWXDYMW7; spf=none (imf10.hostedemail.com: domain of thomas.hellstrom@linux.intel.com has no SPF policy when checking 198.175.65.17) smtp.mailfrom=thomas.hellstrom@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738679400; 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=lAbL/0l6KMc7nqVP2DUrdeWeqlThU/+Tdw9u/t7yoPg=; b=bA06rTbKoo4NZAeYytBK7YR6hyk27cChlKdBVG/c1Is4NpH5Pkzzx9x+p8fqwHt8teKerD wBMCBOGc75POib+bVaQBz5g1KfdrHCpJkBncna+w2IBiK+tRpFZ2aGZdK8UcExbXnMTpYN GFTYFjxNMVgD1kKd3kjsJZE3AGDkW/Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738679400; a=rsa-sha256; cv=none; b=ET1q6Vq8swr90TgZCuoWZaO4bDWJfo2uIL/V0W+Z4krPNolZOI9OE/pKiJnvX45YPpN67y /uzZLc/X/2Xbwf1hC3yYHwdLM7r6egNElRbOeF/PAZX8S01txUvW3KisFeM49IVLso671L PqYmZxcl91yIFH5lrChPVOXUUb9rcKk= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=MWXDYMW7; spf=none (imf10.hostedemail.com: domain of thomas.hellstrom@linux.intel.com has no SPF policy when checking 198.175.65.17) smtp.mailfrom=thomas.hellstrom@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1738679399; x=1770215399; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=lAbL/0l6KMc7nqVP2DUrdeWeqlThU/+Tdw9u/t7yoPg=; b=MWXDYMW7hLjuegsYf9eo49x+Ydd4vURjf6BSG23mEV0+eI8umNkZprf9 IbwtKrO6rRzUWOWJaPQ1SWtYk5bBnRIoY2DDndTTJSSGRDuf/qpe8H8/N kEe0bitEpnDPrQq/fvHSu2V58oBmY0+2wSrg4nGFx/TVS6pD23BI05Jpc FnsB+NN/UTAb31jKB+9UYoE9RdJ6SWJWLVNbtNzzWX0LTDJEqgGEP4fUI wb2LHPyqP2tYB7U7FuXw+CAHWWgSbkwrum+EW1x0vtBLd7GYuZH91UYnO 1QB+S3B+H8gxALGdzAKDlEYk14+HbDmBIwAwntA/UsZjIRBfK5KnWnh5I g==; X-CSE-ConnectionGUID: VEYsnRufRC+tFdZge6HVVw== X-CSE-MsgGUID: 8z5PHT4UQgKtgfmsIyqs6g== X-IronPort-AV: E=McAfee;i="6700,10204,11336"; a="39238440" X-IronPort-AV: E=Sophos;i="6.13,258,1732608000"; d="scan'208";a="39238440" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orvoesa109.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Feb 2025 06:29:55 -0800 X-CSE-ConnectionGUID: RN6d+SumTOSsCLPg3AdQww== X-CSE-MsgGUID: kC63yfL0SO+G5fseY8Womg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="147807634" Received: from lfiedoro-mobl.ger.corp.intel.com (HELO [10.245.246.144]) ([10.245.246.144]) by smtpauth.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Feb 2025 06:29:51 -0800 Message-ID: <3e96aef8009be69858a69d3e49a2bd7fc7d06f5f.camel@linux.intel.com> Subject: Re: [RFC 1/5] mm/hmm: HMM API to enable P2P DMA for device private pages From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Jason Gunthorpe Cc: Yonatan Maman , kherbst@redhat.com, lyude@redhat.com, dakr@redhat.com, airlied@gmail.com, simona@ffwll.ch, leon@kernel.org, jglisse@redhat.com, akpm@linux-foundation.org, GalShalom@nvidia.com, dri-devel@lists.freedesktop.org, nouveau@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org, linux-mm@kvack.org, linux-tegra@vger.kernel.org Date: Tue, 04 Feb 2025 15:29:48 +0100 In-Reply-To: <20250204132615.GI2296753@ziepe.ca> References: <20250128172123.GD1524382@ziepe.ca> <20250129134757.GA2120662@ziepe.ca> <20250130132317.GG2120662@ziepe.ca> <20250130174217.GA2296753@ziepe.ca> <20250203150805.GC2296753@ziepe.ca> <7b7a15fb1f59acc60393eb01cefddf4dc1f32c00.camel@linux.intel.com> <20250204132615.GI2296753@ziepe.ca> Organization: Intel Sweden AB, Registration Number: 556189-6027 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.54.3 (3.54.3-1.fc41) MIME-Version: 1.0 X-Stat-Signature: izgm3r6rh1smujguxawwzmwzs4ak6oi8 X-Rspamd-Queue-Id: CAC21C0008 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1738679398-113002 X-HE-Meta: U2FsdGVkX19gT38CKh0pXGnWaUpPBJipoxIXDHJQfZu16ts5aXbgRHM4n15rhq/1Mf9J2tCkUtFYzY549TJDv52yeaDpPZGnR0JjTLnPTr5A3AlCcuxQT/i1qPGuRhQKvxc4V3yySE2umbV66d/PAhsP94hq5D87HdvtOEwwjgbWopVriSCvdP3TABH7qzHC4r8IjVFNv+1YMUW1Pc2IeGBozaYyvg0eSY9sfrVik7gX15G9HXTsZ5z5aQ7hOc+ZXsJxGfCVOl64hy0fTkv6nV+YyOXMWfKQZymSdhr9wcLN2Z+UXxCXI/h4LIZmXjvsyYWZYQg3GkDm6lSy5XUq/EWRRSczzjGtB7Y+8J/Ugbo5cWqssy9NwEI8nCw4oXeFC4bWA5PT+r5duwROYaL6HlaMio54NIzDQ8A0sS+ywjAC9grL0IpoJtMkuzqTm4/5+M4nYLmYW4/aveOAAGXkE2OC+kaMj3xIq3A3CEdm7W13S5S+VZCs7TVsCrmy7n+JeXMoDOjvyFIzDC0wmoonKmr+pwwxd33jD9JHVVmOXhg6Zwk7UwNJ8twtPKS8pORrmWNRwwCLexdSzjZ9mS/j044DvXFfgMtP4r3tOdcWFotsKZ7q1/d9Reqhfo6ygIegHKi4TGoy5IN4ffW/8HK0YrRzrXie2Z277JyDMYKp4pUoypi7Z7Ckou9d96AcoztMoZIpWxy18xSPSX65XOABYfgxOaHglMO5FK9lUGuPzRCXO9f9RCmY2WF1fmCEsc6dq2cpapsY5hwSa1C1CsBo885+0eIXQTWtu3VafNCBbStKVMphe5nPsJueJHg0DI4mkV8Q/leoMf4YpvxPJmZvla19Cosninvm8hLo+gL7t4lIwbu6DchwWuWpsQ8AR2Z+H2ChZxGHWRjFtjbl2KhO+PlPCsg0IC915HmRIhwgfGXz9G5DgBTEra42aV1/Zm6XvEwg+HKM/44VrawHAbw aQfhOXd1 3cG7S7LYfO8RO/54AW9QISWRookLkJOHKh+66g1su7M/OmY9O+JKUjYT3WmxuKhvWIDS5fHMjY+KN+UcCwk2QUlo2R7DjYz7DzM5MQiwjLZ1UcB8IR1lLh8Y+AZRXUuVJPEJY30Wdx8NP7x56MxTYu/XWBXp5alsGakrbE/sHGmk6433OpumySWwoPNoSjciwr60nwuFHw6yUWtVFT5P67v6kMYBwfli0hn58WeboDO47iRE= 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, 2025-02-04 at 09:26 -0400, Jason Gunthorpe wrote: > On Tue, Feb 04, 2025 at 10:32:32AM +0100, Thomas Hellstr=C3=B6m wrote: > >=20 >=20 > > 1) Existing users would never use the callback. They can still rely > > on > > the owner check, only if that fails we check for callback > > existence. > > 2) By simply caching the result from the last checked dev_pagemap, > > most > > callback calls could typically be eliminated. >=20 > But then you are not in the locked region so your cache is racy and > invalid. I'm not sure I follow? If a device private pfn handed back to the caller is dependent on dev_pagemap A having a fast interconnect to the client, then subsequent pfns in the same hmm_range_fault() call must be able to make the same assumption (pagemap A having a fast interconnect), else the whole result is invalid? >=20 > > 3) As mentioned before, a callback call would typically always be > > followed by either migration to ram or a page-table update. > > Compared to > > these, the callback overhead would IMO be unnoticeable. >=20 > Why? Surely the normal case should be a callback saying the memory > can > be accessed? Sure, but at least on the xe driver, that means page-table repopulation since the hmm_range_fault() typically originated from a page-fault. >=20 > > 4) pcie_p2p is already planning a dev_pagemap callback? >=20 > Yes, but it is not a racy validation callback, and it already is > creating a complicated lifecycle problem inside the exporting the > driver. Yeah, I bet there are various reasons against a callback. I just don't see the performance argument being a main concern.=20 >=20 > Jason /Thomas