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 E864FE69185 for ; Fri, 22 Nov 2024 17:49:18 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id AD3F710EC4C; Fri, 22 Nov 2024 17:49:18 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="i8EJ9Rhm"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.13]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6D57D10EC4C for ; Fri, 22 Nov 2024 17:49:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1732297758; x=1763833758; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=Ubn//LO0M15XbmubkbrVri46UtCBYLBnwCSDBux9ZYA=; b=i8EJ9RhmR+edHJcVj6gFdtSdyc2AAoox7u8G+ipiRa191suF1MjwkVv+ +Ek0RiAMs9PMEtVUbzEDc3gEioP7gOPUyXOmFuXfi2o/hecwPbJ6BFhAo XQ8nSndl6htxOFXczA7iMFE7XjIO5m9GvnzTmpMAv2WXaIw6EZau43KMB QnpQR7jdRyDH5SQpHgY8ysDiwanakModToaptjw7KmQPhkb4lidsD9lgW Jki3+9SM+5gi0wrOQzmQ28haq09lUs54G6bjXFqECLZohTEMuI9baSMif XI+2/g7QUnXtEPPTokoO2A3C9V2dgH9cSQKHMecAPSGpMW2cKOsAg17qG g==; X-CSE-ConnectionGUID: hE5kz9upRFm6nWuYba1LEQ== X-CSE-MsgGUID: 09NcZGRQTeSX16SUgFlUgg== X-IronPort-AV: E=McAfee;i="6700,10204,11264"; a="43526449" X-IronPort-AV: E=Sophos;i="6.12,176,1728975600"; d="scan'208";a="43526449" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Nov 2024 09:49:18 -0800 X-CSE-ConnectionGUID: w+4vANykRCWgfbx9HpRODw== X-CSE-MsgGUID: bPapHNRsSPu+Cnw0gGQu1w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,176,1728975600"; d="scan'208";a="91443468" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.142]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Nov 2024 09:49:17 -0800 Date: Fri, 22 Nov 2024 09:49:16 -0800 Message-ID: <85serjjh0j.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Umesh Nerlige Ramappa Cc: Matthew Brost , intel-xe@lists.freedesktop.org, Jonathan Cavitt Subject: Re: [PATCH] drm/xe/oa: Disallow OA from being enabled on active exec_queue's In-Reply-To: <85ttc0j8lv.wl-ashutosh.dixit@intel.com> References: <20241119013256.680030-1-ashutosh.dixit@intel.com> <851pz76ie6.wl-ashutosh.dixit@intel.com> <85ttc0j8lv.wl-ashutosh.dixit@intel.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-redhat-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-BeenThere: intel-xe@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel Xe graphics driver List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Thu, 21 Nov 2024 18:38:36 -0800, Dixit, Ashutosh wrote: > > Doing what I outlined above (submitting to the user exec queue), or doing > what you are suggesting (submitting directly to the ring), is not an > insignificant amount of work. E.g. submitting a MI_LRI command to the ring > requires allocating the batch buffer in the user/exec_queue VM. And even > then writing directly to the ring would race with the scheduler potentially > submitting simultaneously to the same ring (see guc_exec_queue_run_job). Incidentally, for the above reason, submitting directly to the ring would need introduction of a new lock in the submission path and therefore will likely not fly. In Xe, as opposed to i915, everything is submitted to the scheduler and it is only the scheduler which submits to the ring. Therefore, if we ever do this, my guess we'd have to submit to the user exec queue instead, as I was saying. I am not sure if there will still be locking issues in the kernel allocating its batches from the userspace VM, but they are likely to be less serious than introducing a new lock in the submission path. Ashutosh