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 A40C9D3F081 for ; Wed, 28 Jan 2026 15:52:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 0D30010E725; Wed, 28 Jan 2026 15:52:26 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=collabora.com header.i=@collabora.com header.b="IJZhk2PP"; dkim-atps=neutral Received: from bali.collaboradmins.com (bali.collaboradmins.com [148.251.105.195]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4D7D110E2CE for ; Wed, 28 Jan 2026 15:52:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1769615542; bh=a8VhmOLmrc5zlRFrcQy51JiIdCYECH8tHqCCYjnJs+A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IJZhk2PPJI0xFdJmapUgYgZL+2xVipUiqxmbAyUyYLVb00e6Azy25/Wh2G6g+ciiG UQu8o8JY6nBreRjiQ2d9crVhXYN4TMkFx4yNKV1KB3A+plDuhuWoxS/16an0BQz0Ff avGWiVf5NlvrYeTE055PHW7FjNJYG+WnvgE2ZjYddfkThPAsevCW9W+sNq21kFG/rt xhNBLd5TSCkbSsBJKrUn6hsN8h8jrbGnmc7MTyBSbL1cYfFr0S70sGc8gbEM5u0/8H nladsm7ktutnW6M1G7NjVf3Czj6wrlpw59vMkvqGS1w+d3v8l7HZJ3ul877l/JKdhp 2Y/Kf04bu23QA== Received: from fedora (unknown [IPv6:2a01:e0a:2c:6930:d919:a6e:5ea1:8a9f]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: bbrezillon) by bali.collaboradmins.com (Postfix) with ESMTPSA id 0D26617E00AC; Wed, 28 Jan 2026 16:52:22 +0100 (CET) Date: Wed, 28 Jan 2026 16:52:14 +0100 From: Boris Brezillon To: Akash Goel Cc: Steven Price , Liviu Dudau , =?UTF-8?B?QWRyacOhbg==?= Larumbe , dri-devel@lists.freedesktop.org, David Airlie , Simona Vetter , Rob Clark , Sean Paul , Konrad Dybcio , Akhil P Oommen , Maarten Lankhorst , Maxime Ripard , Thomas Zimmermann , Dmitry Osipenko , Chris Diamand , Danilo Krummrich , Matthew Brost , Thomas =?UTF-8?B?SGVsbHN0csO2bQ==?= , Alice Ryhl , kernel@collabora.com, nd@arm.com Subject: Re: [PATCH v1 9/9] drm/panthor: Add a GEM shrinker Message-ID: <20260128165214.248ef333@fedora> In-Reply-To: <77dec915-da6d-4ff5-b949-a883288f2672@arm.com> References: <20260109130801.1239558-1-boris.brezillon@collabora.com> <20260109130801.1239558-10-boris.brezillon@collabora.com> <714d2b72-67df-4590-9943-6289886c0a89@arm.com> <20260121155238.2a6c0274@fedora> <77dec915-da6d-4ff5-b949-a883288f2672@arm.com> Organization: Collabora X-Mailer: Claws Mail 4.3.1 (GTK 3.24.51; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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" Hi Akash, On Wed, 28 Jan 2026 11:21:43 +0000 Akash Goel wrote: > Sorry I have a doubt. > > Should we update the panthor_gem_sync() function to ensure pages can't > get reclaimed whlilst they are being synced ?. > > panthor_ioctl_bo_sync() takes a reference on the BO before calling > panthor_gem_sync(). But I think due to this patch, the backking pages > can get released in the middle of sync loop. > > sgt = panthor_gem_get_dev_sgt(bo); > if (IS_ERR(sgt)) > return PTR_ERR(sgt); > for_each_sgtable_dma_sg(sgt, sgl, count) { > dma_addr_t paddr = sg_dma_address(sgl); > size_t len = sg_dma_len(sgl); > > dma_sync_single_for_device(); > dma_sync_single_for_cpu(); > } > > > Please can you confirm. I think you're right. We either need to pin/unpin around a sync operation, or we need to take the resv lock to make sure the GEM is not reclaimed while we do that. It probably makes sense to do the latter, since we don't want to prematurely pull back the data from the swap just to synchronize CPU accesses (the dma_unmap_sgtable() in panthor_gem_dev_map_cleanup_locked() should have synchronized things for us on a swapout). I'll fix that before posting a v2. Thanks, Boris