From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 277281F9F50 for ; Wed, 18 Dec 2024 18:09:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734545341; cv=none; b=ebaB6MJO7HYRbp4jWnYP0FDHZMaZuRuh5ySTaKzLIpcuwIdfZHM8zCp+3lo09ZGm13kfX1j0yQgQL3zPrLfvTjM0314HaEql/mF/LXw4WXWf7ph7qWWnLOG0uh5AQiKa/fraPtoONJEemsNASgs6LH0RvWjGYMr70g90RRPnP6A= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1734545341; c=relaxed/simple; bh=MKn7tx70E7Zta8f49WhpOqa+40htXcaNf6+dSCs6yH0=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jMi6AjQaAnPBYEO8+NhZwZsHbxhnOx2y+DgAJuBO6BPAI/xb6YWHXADapnIbPU8H2keKgHZ5LmmoCtkPqqPyp1NsYKbkJ0Hapn3Rcm3xdTIUJOFEP9QiHP6vS4OdDeZaNRmcT2lon7dltKEFA9k8C1nHFpTOwzwhXkMfF2HMTH4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=jmdwTf2R; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="jmdwTf2R" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D649C4CECD; Wed, 18 Dec 2024 18:09:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1734545340; bh=MKn7tx70E7Zta8f49WhpOqa+40htXcaNf6+dSCs6yH0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=jmdwTf2RpkGRVnsDOiIEDfmLur/4WprwwADTl2WmEGNVuVKB6uWS/UG6gB4kLRF0y dwTD9ntK44qECEyciLVv9ex3hmp01mpEnv8nRjTPPFoQ9U7TgIs2ZSBnRSgNuFmhSp hOhuz2N1PwDlKKvKg+RPGOx3PW2H2zeOr3e31BGuMQu3xgCp7+dPbJd2UrdlcWNt28 hweCI2lbqN0mTlb91Ao0XFEPjUgrTjSnSn0XxdmJMTkTHTFlmH71CM9MqJ+2EDZEGp GQVA/DCB7VdraeMNIrmdKwZS9F0s9j/wJnMVtTfWwIkBspOHKmln0m+0dTgISDKNgj LfDcRthnvyLiA== Date: Wed, 18 Dec 2024 08:08:59 -1000 From: Tejun Heo To: Matthew Brost Cc: Alex Deucher , Chris Rankin , Christian Koenig , Tvrtko Ursulin , LKML , amd-gfx@lists.freedesktop.org Subject: Re: [WARNING][AMDGPU] WQ_MEM_RECLAIM with Radeon RX 6600 Message-ID: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hello, sorry about the delay. On Mon, Dec 16, 2024 at 04:34:00PM -0800, Matthew Brost wrote: > > However, after further discussion, I think the warning is actually a > > false positive. See this discussion: > > https://lists.freedesktop.org/archives/amd-gfx/2024-November/117349.html > > > > From the thread: > > "Question is - does check_flush_dependency() need to skip the > > !WQ_MEM_RECLAIM flushing WQ_MEM_RECLAIM warning *if* the work is already > > running *and* it was called from cancel_delayed_work_sync()?" > > > > See my reply just now [1] — I’m going to have to disagree with AMD's > assessment, but I’m not certain. > > Again, I believe Tejun is the authority here. I think we can skip the warning if the flushing is coming from cancel*_work_sync() as flush takes place iff the work item already has a worker running - ie. it can't be blocked from lack of memory. Tvrtko, can you write up a patch to exclude the condition from check_flush_dependency()? I think it can just skip check_flush_dependency() when @from_cancel is set. Taking a step back, if an actual dependency develops in the future - memory reclaim actually blocking on gpu work items, one way to handle that would be adding subsystem-wide workqueues so that the rescuer can be shared across GPU drivers / devices. As long as they don't depend on each other for making forward progress, which they most likely wouldn't, sharing a rescuer across them is completely fine. Thanks. -- tejun