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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6E63FC433F5 for ; Wed, 29 Sep 2021 08:53:30 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id 376AF613A6 for ; Wed, 29 Sep 2021 08:53:30 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 376AF613A6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A14AA6E195; Wed, 29 Sep 2021 08:53:29 +0000 (UTC) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by gabe.freedesktop.org (Postfix) with ESMTPS id E487C6E195 for ; Wed, 29 Sep 2021 08:53:28 +0000 (UTC) X-IronPort-AV: E=McAfee;i="6200,9189,10121"; a="212148776" X-IronPort-AV: E=Sophos;i="5.85,331,1624345200"; d="scan'208";a="212148776" Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Sep 2021 01:53:28 -0700 X-IronPort-AV: E=Sophos;i="5.85,331,1624345200"; d="scan'208";a="554617859" Received: from pathanas-mobl1.ger.corp.intel.com (HELO [10.252.38.52]) ([10.252.38.52]) by fmsmga003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Sep 2021 01:53:26 -0700 To: Matthew Auld Cc: Intel Graphics Development , =?UTF-8?Q?Thomas_Hellstr=c3=b6m?= , Daniel Vetter , stable@vger.kernel.org References: <20210830121006.2978297-1-maarten.lankhorst@linux.intel.com> <20210830121006.2978297-9-maarten.lankhorst@linux.intel.com> From: Maarten Lankhorst Message-ID: Date: Wed, 29 Sep 2021 10:53:26 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [Intel-gfx] [PATCH 08/19] drm/i915: Fix runtime pm handling in i915_gem_shrink X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" Op 29-09-2021 om 10:37 schreef Matthew Auld: > On Mon, 30 Aug 2021 at 13:10, Maarten Lankhorst > wrote: >> We forgot to call intel_runtime_pm_put on error, fix it! >> >> Signed-off-by: Maarten Lankhorst >> Fixes: cf41a8f1dc1e ("drm/i915: Finally remove obj->mm.lock.") >> Cc: Thomas Hellström >> Cc: Daniel Vetter >> Cc: # v5.13+ > How does the err handling work? gem_shrink is meant to return the > number of pages reclaimed which is an unsigned long, and yet we are > also just returning the err here? Fortunately it looks like nothing is > calling gem_shrinker with an actual ww context, so nothing will hit > this yet? I think the interface needs to be reworked or something. We should probably make it signed in the future when used. It should never hit the LONG_MAX limit, since max value returned would be ULONG_MAX >> PAGE_SHIFT, assuming the entire address space is filled with evictable buffers. I've kept the ww lock, in case we want to evict in the future. Without ww context the buffers are trylocked, with ww we can evict the entire address space as much as possible. In most cases we only want to evict idle objects, in that case no ww is needed. Pushed just this patch, thanks for feedback. :) ~Maarten