From patchwork Wed Jul 31 00:31:14 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Matthew Brost X-Patchwork-Id: 13747979 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 9B092C52D54 for ; Wed, 31 Jul 2024 00:30:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A238410E262; Wed, 31 Jul 2024 00:30:32 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="kAMRvlAb"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.13]) by gabe.freedesktop.org (Postfix) with ESMTPS id 42F1C10E04A; Wed, 31 Jul 2024 00:30:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1722385831; x=1753921831; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=d8JIn2ZBV5v6QHx36vp89HRxtaEmlG8HaXXFjyYOxO4=; b=kAMRvlAbFdEi3wiUGGqUUnjDxnnWMlI6PaA3I8MUlb/0KBkgTtiqZy9T esGrLleGck7GM1ZWB4ixTp/DwDl1TuRAb0xGl7SarEMBRkZEhB9A7/iq5 rxt5N9iMWIl7tEpNC2XNsEf5fv+hM+JHJXfaWxOffJ6W776bgLMITO5kw nPbsISvPqc0WBAKI0LL8SF7b2wfW58iaHrn/hy4hiFF9y422g8CJyKkae hf2ElVM76q6wTeJHkP+lvvsakZUoB6zbKxnPXInoCQgdusCnBlm35f/hm zI4sqFAPTWur8ElPl0UL90TR6iu6Zg2kIOv/kz4FDenvT24gdq0rB+Woq w==; X-CSE-ConnectionGUID: tRJOJZXpTZiGu39DaWLPSw== X-CSE-MsgGUID: 71pfAPpNSKq2e4HUkpmyOA== X-IronPort-AV: E=McAfee;i="6700,10204,11149"; a="23156072" X-IronPort-AV: E=Sophos;i="6.09,248,1716274800"; d="scan'208";a="23156072" Received: from fmviesa002.fm.intel.com ([10.60.135.142]) by fmvoesa107.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jul 2024 17:30:31 -0700 X-CSE-ConnectionGUID: qZuQNejkSsGM5VXM0quvzw== X-CSE-MsgGUID: j3QBpmjZS4etI25fHRlklA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.09,248,1716274800"; d="scan'208";a="77781796" Received: from lstrano-desk.jf.intel.com ([10.54.39.91]) by fmviesa002-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Jul 2024 17:30:30 -0700 From: Matthew Brost To: intel-xe@lists.freedesktop.org, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org Cc: tj@kernel.org, jiangshanlai@gmail.com, christian.koenig@amd.com, ltuikov89@gmail.com, daniel@ffwll.ch Subject: [PATCH v2 0/5] Use user-defined workqueue lockdep map for drm sched Date: Tue, 30 Jul 2024 17:31:14 -0700 Message-Id: <20240731003119.2422940-1-matthew.brost@intel.com> X-Mailer: git-send-email 2.34.1 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" By default, each DRM scheduler instance creates an ordered workqueue for submission, and each workqueue creation allocates a new lockdep map. This becomes problematic when a DRM scheduler is created for every user queue (e.g., in DRM drivers with firmware schedulers like Xe) due to the limited number of available lockdep maps. With numerous user queues being created and destroyed, lockdep may run out of maps, leading to lockdep being disabled. Xe mitigated this by creating a pool of workqueues for DRM scheduler use. However, this approach also encounters issues if the driver is unloaded and reloaded multiple times or if many VFs are probed. To address this, we propose creating a single lockdep map for all DRM scheduler workqueues, which will also resolve issues for other DRM drivers that create a DRM scheduler per user queue. This solution has been tested by unloading and reloading the Xe driver. Before this series, around 30 driver reloads would result in lockdep being turned off. After implementing the series, the driver can be unloaded and reloaded hundreds of times without issues. v2: - Split workqueue changes into multiple patches - Add alloc_workqueue_lockdep_map (Tejun) - Don't RFC Matt Matthew Brost (5): workqueue: Split alloc_workqueue into internal function and lockdep init workqueue: Change workqueue lockdep map to pointer workqueue: Add interface for user-defined workqueue lockdep map drm/sched: Use drm sched lockdep map for submit_wq drm/xe: Drop GuC submit_wq pool drivers/gpu/drm/scheduler/sched_main.c | 11 ++++ drivers/gpu/drm/xe/xe_guc_submit.c | 60 +-------------------- drivers/gpu/drm/xe/xe_guc_types.h | 7 --- include/linux/workqueue.h | 25 +++++++++ kernel/workqueue.c | 75 ++++++++++++++++++++------ 5 files changed, 97 insertions(+), 81 deletions(-)