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 3EA23C0219B for ; Tue, 11 Feb 2025 19:50:25 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 057A210E745; Tue, 11 Feb 2025 19:50:25 +0000 (UTC) Authentication-Results: gabe.freedesktop.org; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.b="JEgQgewP"; dkim-atps=neutral Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.8]) by gabe.freedesktop.org (Postfix) with ESMTPS id 3B80A10E745 for ; Tue, 11 Feb 2025 19:50:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1739303423; x=1770839423; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=sYcafgWfUg3qAvv/YW4kVzl3TfXNbzbA/o3u3NPiGXM=; b=JEgQgewPteC+NDgv7oyfQlDTmxGwdF9J0y75wAxnJvOoYTreVjXZAImd ybioHD1XcevSUeFFxfxpQdsl83W1pxdu+se/VSfZ4MaKjbA5O2exO3cg+ DaXiiVoirwlLdgffgB4ejxI2KHgeLXze0P7cGMAQRQx+xMoWwN/XJJU2t NBhOsHEYHjSVMQPWoD8lG5NdL78xF2rFDNcqKIyZIRTKd50qFnwmJ+ED1 WzGnHGbq6FMuurdNE206VXDue6f30fLvKLn8OX5e74qUUO6TEosmwCMCB soylmVY2b3GY9eCGlmQQsBWPUL0iYeGuHwXuo4MWqckBSIDwFJhvT8j0O Q==; X-CSE-ConnectionGUID: Lg6o2Of4SSinTRjikfvpmQ== X-CSE-MsgGUID: cQ250avHQaWjL9Vpxppf4w== X-IronPort-AV: E=McAfee;i="6700,10204,11342"; a="57474735" X-IronPort-AV: E=Sophos;i="6.13,278,1732608000"; d="scan'208";a="57474735" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Feb 2025 11:50:22 -0800 X-CSE-ConnectionGUID: 60VjhTC6QIGRigfQIWUJPA== X-CSE-MsgGUID: rSpFMGEVS0mNVA/4m3LbFA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.12,224,1728975600"; d="scan'208";a="113087718" Received: from orsosgc001.jf.intel.com (HELO orsosgc001.intel.com) ([10.165.21.142]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Feb 2025 11:50:22 -0800 Date: Tue, 11 Feb 2025 11:50:22 -0800 Message-ID: <85cyfo2rcx.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Harish Chegondi Cc: Subject: Re: [PATCH v9 2/8] drm/xe/uapi: Introduce API for EU stall sampling In-Reply-To: <85h6512ybc.wl-ashutosh.dixit@intel.com> References: <36d701413aeb171c86d5dd2ce7272918eb4ab818.1739193510.git.harish.chegondi@intel.com> <85h6512ybc.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 Mon, 10 Feb 2025 15:07:51 -0800, Dixit, Ashutosh wrote: > > > +static int set_prop_eu_stall_sampling_rate(struct xe_device *xe, u64 value, > > + struct eu_stall_open_properties *props) > > +{ > > + value = div_u64(value, 251); > > + if (value == 0 || value > 7) { > > + drm_dbg(&xe->drm, "Invalid EU stall sampling rate %llu\n", value); > > + return -EINVAL; > > + } > > + props->sampling_rate_mult = value; > > + return 0; > > +} > > + > > +static int set_prop_eu_stall_wait_num_reports(struct xe_device *xe, u64 value, > > + struct eu_stall_open_properties *props) > > +{ > > + unsigned int max_wait_num_reports; > > + > > + max_wait_num_reports = num_data_rows(per_xecore_buf_size * XE_MAX_DSS_FUSE_BITS); > > This seems wrong. Instead of XE_MAX_DSS_FUSE_BITS, shouldn't we use the > value returned by xe_gt_topology_mask_last_dss()? > > Note that a large value can result in the poll/read never getting > unblocked! > > To solve this issue I think num_xecore should be maintained in struct > xe_eu_stall_gt. Though let's see what happens to 'struct xe_device *' arg > to these functions if we do this. Also, even with num_xecore (instead of XE_MAX_DSS_FUSE_BITS), I think max_wait_num_reports = num_data_rows(per_xecore_buf_size * num_xecore) is a very large value. If user specifies this value, we will almost certainly start dropping data. So maybe max_wait_num_reports should be half of this value? Or do we just leave this max and let the user deal with -EIO returns? Anyway something to think about.