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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 29538CA0ED1 for ; Mon, 18 Aug 2025 16:42:57 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 72F2910E4A3; Mon, 18 Aug 2025 16:42:56 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="c9J0tRLV"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.16]) by gabe.freedesktop.org (Postfix) with ESMTPS id AC7BB10E4A3; Mon, 18 Aug 2025 16:42:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1755535375; x=1787071375; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=FFRgUjm1Gro1I+69P/TMbAic2wfSm8DMVKGUgEm0vxw=; b=c9J0tRLVf010DXS5RDRVcYlG4pIubfPJ8Mfjede6UEr3PsfDiOqQjorm 0HSnnaKGcUJETlCuUNPzuLg+GwtKDjONPkxMopfE6frF1qoAyP7lko4z9 yfuOn3+PiAsm0dDga7uu2t7FQiCbcd/6qbyB7dWHvp0Y8O90TjXsSdkkg SyX8ZGpK+f7NnNgk5oll0LjjbTuKGKtHPE1/2PpEm3xU77yFVPnzcP6Sl SXi7yuFCvy7pGKgEH6n+9V6f4Dry0j2pxWM0GIsTM0anM+PCRX1fZRAzw 8wT72JfeI2fDDdvBjI7Fh6P1YSjqWcxnrDErh4pNaG95lxF5WCXfqVdxj Q==; X-CSE-ConnectionGUID: 95U2SEwIRke+rfNCyaZjhg== X-CSE-MsgGUID: 5zN2gpUjSWGO0oGw9v/Svw== X-IronPort-AV: E=McAfee;i="6800,10657,11526"; a="57913911" X-IronPort-AV: E=Sophos;i="6.17,300,1747724400"; d="scan'208";a="57913911" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa108.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Aug 2025 09:42:55 -0700 X-CSE-ConnectionGUID: hg58vD3gT1C5B79/FUkiiQ== X-CSE-MsgGUID: wD+yurJLT02ZIM7X6sfNmA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.17,300,1747724400"; d="scan'208";a="167863384" Received: from abityuts-desk.ger.corp.intel.com (HELO [10.245.244.38]) ([10.245.244.38]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 18 Aug 2025 09:42:52 -0700 Message-ID: Subject: Re: [RFC PATCH 1/6] mm/mmu_notifier: Allow multiple struct mmu_interval_notifier passes From: Thomas =?ISO-8859-1?Q?Hellstr=F6m?= To: Jason Gunthorpe , Matthew Brost Cc: intel-xe@lists.freedesktop.org, Andrew Morton , Simona Vetter , Dave Airlie , dri-devel@lists.freedesktop.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Christian =?ISO-8859-1?Q?K=F6nig?= Date: Mon, 18 Aug 2025 18:42:36 +0200 In-Reply-To: <20250818163617.GI599331@ziepe.ca> References: <20250809135137.259427-1-thomas.hellstrom@linux.intel.com> <20250809135137.259427-2-thomas.hellstrom@linux.intel.com> <20250818160726.GH599331@ziepe.ca> <20250818163617.GI599331@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-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Mon, 2025-08-18 at 13:36 -0300, Jason Gunthorpe wrote: > On Mon, Aug 18, 2025 at 09:25:20AM -0700, Matthew Brost wrote: > > I think this choice makes sense: it allows embedding the wait state > > from > > the initial notifier call into the pass structure. Patch [6] shows > > this > > by attaching the issued TLB invalidation fences to the pass. Since > > a > > single notifier may be invoked multiple times with different ranges > > but > > the same seqno, >=20 > That should be explained, but also seems to be a bit of a different > issue.. >=20 > If the design is really to only have two passes and this linked list > is about retaining state then there should not be so much freedom to > have more passes. Actually the initial suggestion was two passes only. Then I thought I saw a use-case for even three passes and added the multi-pass thing, but I think it turned out we didn't have such a use-case. IMO we could restrict it to two-pass. Matthew, that should be completely OK for the SVM use-case, right? /Thomas >=20 > Jason