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 5B6E2EB64D9 for ; Fri, 7 Jul 2023 02:18:34 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id ED41310E063; Fri, 7 Jul 2023 02:18:33 +0000 (UTC) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by gabe.freedesktop.org (Postfix) with ESMTPS id 8B32C10E4EF for ; Fri, 7 Jul 2023 02:18:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1688696312; x=1720232312; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=JHPnh1JMeleH2YcXvELpQo+vH/e5GTH1cO1H96m+5s4=; b=iWraXHDfdVKBSGA0OfThXIcOh7kehui8SHFO/bTwPOxmzzv1Z29LCqo+ JzEsSxkprO50mIIA+urs0VpLK8D8di09aSD9xeW+ROHQyA8mPpD4E8CB6 RjKsOioYBAkSLGEK8ozciMAjdLSgl+m9AgcypfvPlDxxkXDpqHcAzEL8u pV96MSfOjYC2VHuGnPSU/ahGp9Tbfwjy+9RWd6dTW1zSgEl3b5fWSBA7G BF9m0uaZkEE8U3kJMXSDWoQ45RgpZM14XMAl2H2d/lENLVw4IpciFJQoJ sC4pZKZ0EOAhqpcOFbFFXxYeQ7+tO/P10vFW1SKFD4/sHXzdFag1JeXl1 Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10763"; a="366362457" X-IronPort-AV: E=Sophos;i="6.01,187,1684825200"; d="scan'208";a="366362457" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga102.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 19:18:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10763"; a="843936896" X-IronPort-AV: E=Sophos;i="6.01,187,1684825200"; d="scan'208";a="843936896" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.197.88]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Jul 2023 19:18:31 -0700 Date: Thu, 06 Jul 2023 19:18:04 -0700 Message-ID: <87a5w8cvmr.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Iddamsetty, Aravind" In-Reply-To: References: <20230627122113.1472532-1-aravind.iddamsetty@intel.com> <20230627122113.1472532-3-aravind.iddamsetty@intel.com> <87mt09daqu.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-pc-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 Subject: Re: [Intel-xe] [PATCH v2 2/2] drm/xe/pmu: Enable PMU interface 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: , Cc: Bommu Krishnaiah , intel-xe@lists.freedesktop.org, Tvrtko Ursulin Errors-To: intel-xe-bounces@lists.freedesktop.org Sender: "Intel-xe" On Thu, 06 Jul 2023 06:42:29 -0700, Iddamsetty, Aravind wrote: > Hi Aravind, > On 06-07-2023 08:09, Dixit, Ashutosh wrote: > > On Tue, 27 Jun 2023 05:21:13 -0700, Aravind Iddamsetty wrote: > > >> +static u64 __engine_group_busyness_read(struct xe_gt *gt, u64 config) > >> +{ > >> + u64 val = 0; > >> + > >> + switch (config) { > >> + case XE_PMU_RENDER_GROUP_BUSY(0): > >> + val = xe_mmio_read32(gt, XE_OAG_RENDER_BUSY_FREE); > >> + break; > >> + case XE_PMU_COPY_GROUP_BUSY(0): > >> + val = xe_mmio_read32(gt, XE_OAG_BLT_BUSY_FREE); > >> + break; > >> + case XE_PMU_MEDIA_GROUP_BUSY(0): > >> + val = xe_mmio_read32(gt, XE_OAG_ANY_MEDIA_FF_BUSY_FREE); > >> + break; > >> + case XE_PMU_ANY_ENGINE_GROUP_BUSY(0): > >> + val = xe_mmio_read32(gt, XE_OAG_RC0_ANY_ENGINE_BUSY_FREE); > >> + break; > >> + default: > >> + drm_warn(>->tile->xe->drm, "unknown pmu event\n"); > >> + } > >> + > >> + return xe_gt_clock_interval_to_ns(gt, val * 16); > >> +} > > > > A few questions on just the above function first: > > > > 1. OK so these registers won't be available to VF's, but any idea what > > these counts are when VF's are active? > > VF's cannot access the registers but the counters will be incrementing > if respective engines are busy and can be monitored from PF and that > will be across all VFs. Ok, good. > > > > > 2. When would these 32 bit registers overflow? Let us say a group is > > continuously busy and we are running at 1 GHz, the registers would > > overflow in 4 seconds (max value 4G)? > > Based on BSPEC:52071 they use MHZ clock assuming the default 24MHz, it > would take around 5726 secs to overflow. OK, overflow should not be an issue then. Though I have seen 19.2 and 38.4 MHz in OA. Also, if these are OAG registers, OA timestamp freq can be different from CS timestamp freq, so not sure if that needs to be handled. See i915_perf_oa_timestamp_frequency() in i915. > > > > > 3. What is the multiplication by 16 (not factored above in 2.)? I don't see > > that in Bspec. > > These counters are incremented based on crystal clock frequency and we > need to convert to CS time base hence a 16x mul. BSPEC:52071 Hmm still don't see the 16x mul in BSPEC:52071. Anyway. Also, could you please explain where the requirement to expose these OAG group busy/free registers via the PMU is coming from? Since these are OA registers presumably they can be collected using the OA subsystem. The i915 PMU I believe deduces busyness by sampling the RING_CTL register using a timer. So these registers look better since you can get these busyness values directly. On the other hand you can only get busyness for an engine group and things like compute seem to be missing? Also, would you know about plans to expose other kinds of busyness-es? I think we may be exposing per-VF and also per-client busyness via PMU. Not sure what else GuC can expose. Knowing all this we can better understand how these particular busyness values will be used. Thanks. -- Ashutosh