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 B6B4BC00528 for ; Mon, 24 Jul 2023 16:31:49 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 8282D10E0D1; Mon, 24 Jul 2023 16:31:49 +0000 (UTC) Received: from mga12.intel.com (mga12.intel.com [192.55.52.136]) by gabe.freedesktop.org (Postfix) with ESMTPS id F22FA10E0D1 for ; Mon, 24 Jul 2023 16:31:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1690216308; x=1721752308; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version; bh=D9OW54KHYZGaCsI30l0Yx+nAv/VaC4uBzzabnDk9whU=; b=BrQ13MLHx1PIi8r3U3CrTl94duSR7FI8hZmwc3mzVKlxpVS36W/maj3C 5rDSpNbD5LCpGVudqGt9iKjTLGC4ECR+bvOSTlr814La0/UjWI5FEoQba YZ/fH7xS42XCc6u+LBxijVKhvcB5X8tLCqupKxBkPJouSE3Rjc8Y8mlR3 DTQlWmw2n2TuKntanUpE5hBD7M5KOKutG/NMbT2v1c1/ft/l1rizHjhNd ls60SWW+QwSLClYHzXlagg+NWOCcd1a7RTpr+Z9En4nV4CGKaf/HAAC7T ZYqEzebkVENhdF2D4zh7kwzDWscRUHCpyzklPvml4kYuAIo7o1R/2mAHA g==; X-IronPort-AV: E=McAfee;i="6600,9927,10781"; a="347096596" X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="scan'208";a="347096596" Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga106.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jul 2023 09:31:47 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10781"; a="849699256" X-IronPort-AV: E=Sophos;i="6.01,228,1684825200"; d="scan'208";a="849699256" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.229.56]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Jul 2023 09:31:46 -0700 Date: Mon, 24 Jul 2023 09:31:46 -0700 Message-ID: <87zg3lp8y5.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: "Iddamsetty, Aravind" In-Reply-To: <42bb140d-2faf-43d3-a027-fe430b3682e5@intel.com> References: <20230627122113.1472532-1-aravind.iddamsetty@intel.com> <20230627122113.1472532-3-aravind.iddamsetty@intel.com> <87cz0mqdpi.wl-ashutosh.dixit@intel.com> <877cqsrg65.wl-ashutosh.dixit@intel.com> <875y6cqy6p.wl-ashutosh.dixit@intel.com> <8fd9bc04-b737-0acd-a0c9-4f163c1a117c@intel.com> <87351dqpcr.wl-ashutosh.dixit@intel.com> <42bb140d-2faf-43d3-a027-fe430b3682e5@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 Mon, 24 Jul 2023 09:05:53 -0700, Iddamsetty, Aravind wrote: > > On 24-07-2023 21:22, Dixit, Ashutosh wrote: > Hi Ashutosh, > > > On Mon, 24 Jul 2023 01:03:23 -0700, Iddamsetty, Aravind wrote: > > > > Hi Aravind, > > > >> On 22-07-2023 11:34, Dixit, Ashutosh wrote: > >>>> On Fri, 21 Jul 2023 16:36:02 -0700, Dixit, Ashutosh wrote: > >>>> On Fri, 21 Jul 2023 04:51:09 -0700, Iddamsetty, Aravind wrote: > >>>>>>> +void engine_group_busyness_store(struct xe_gt *gt) > >>>>>>> +{ > >>>>>>> + struct xe_pmu *pmu = >->tile->xe->pmu; > >>>>>>> + unsigned int gt_id = gt->info.id; > >>>>>>> + unsigned long flags; > >>>>>>> + > >>>>>>> + spin_lock_irqsave(&pmu->lock, flags); > >>>>>>> + > >>>>>>> + store_sample(pmu, gt_id, __XE_SAMPLE_RENDER_GROUP_BUSY, > >>>>>>> + __engine_group_busyness_read(gt, XE_PMU_RENDER_GROUP_BUSY(0))); > >>>>>>> + store_sample(pmu, gt_id, __XE_SAMPLE_COPY_GROUP_BUSY, > >>>>>>> + __engine_group_busyness_read(gt, XE_PMU_COPY_GROUP_BUSY(0))); > >>>>>>> + store_sample(pmu, gt_id, __XE_SAMPLE_MEDIA_GROUP_BUSY, > >>>>>>> + __engine_group_busyness_read(gt, XE_PMU_MEDIA_GROUP_BUSY(0))); > >>>>>>> + store_sample(pmu, gt_id, __XE_SAMPLE_ANY_ENGINE_GROUP_BUSY, > >>>>>>> + __engine_group_busyness_read(gt, XE_PMU_ANY_ENGINE_GROUP_BUSY(0))); > >>> > >>> Here why should we store everything, we should store only those events > >>> which are enabled? > >> > >> The events are enabled only when they are opened which can happen after > >> the device is suspended hence we need to store all. As in the present > >> case device is put to suspend immediately after probe and event is > >> opened post driver load is done. > > > > I don't think we can justify doing expensive PCIe reads and increasing the > > time to go into runtime suspend, when PMU might not being used at all. > > > > If we store only enabled samples and start storing them only after they are > > enabled, what would be the consequence of this? The first non-zero sample > > seen by the perf tool would be wrong and later samples will be fine? > > Why do you say it is wrong perf reports relative from the time an event > is opened. I am asking you what is the consequence. Initial values will all be zero and then there is some activity and we get a non zero value but this will include all the previous activity so the first difference we send to perf will be large/wrong I think. > > > > > If there is a consequence, we might have to go back to what I was saying > > earlier about waking the device up and reading the enabled counter when > > xe_pmu_event_start happens, to initialize the counter values. I am assuming > > this will work? > > xe_pmu_event_start can be called when device is in suspend so we shall > not wake up the device i.e event being enabled when in suspend, so if we > do not store while going to suspend we will not have any value to > consider when event is enabled after suspend as we need to present > relative value. That is why I am saying wake up the device and initialize the counters in xe_pmu_event_start. > > > > Doing this IMO would be better than always doing these PCIe reads on > > runtime suspend even when PMU is not being used > > we have been doing these in i915 not sure if it affected any timing > requirements for runtime suspend. Hmm i915 indeed seems to be reading the RC6 residency in __gt_park even when RC6 event is not enabled or PMU might not be used. @Tvrtko, any comments here? Thanks. -- Ashutosh