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 AA9E0C4332F for ; Mon, 7 Nov 2022 00:08:33 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 3336110E1C7; Mon, 7 Nov 2022 00:08:23 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2626110E111; Mon, 7 Nov 2022 00:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667779700; x=1699315700; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version:content-transfer-encoding; bh=9DOoUZdq46nHGydD6VuBdF2sql8gfDA2iF5/4kW1zkM=; b=GJ+HkhqI3ZaRF+0sBSa7OL+bjRm4wwdSkMMHOTGfwUm4RBi9ziZfqVKk XkUne5Ady9y74mrewSzLR4Px3dgTvsNwR5QkuV5VsjBmALC+xnyio2UAq 8kGEJ0Uojx8MN+Pa0/eghMZg9bYNSoJZNhPhTeqtcVIiLlQ2MScu22YuK niVdzuOtRP3AFB8AFyh2T74RbTP5b0ghoJ/AzDaQ25Vpp3r97LmADk/9W bnqeY3OgWr8WfCgl8Eyl1HBR6CHMiFEe7qlVkOA5w/LlGd+/PECHLcpWf VxZ49i9KRbrUSCH034B8b3wsn+vyOTW5/+yFmTxHD00wmaZdOZZ04nNMG Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10523"; a="307917537" X-IronPort-AV: E=Sophos;i="5.96,143,1665471600"; d="scan'208";a="307917537" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2022 16:08:14 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10523"; a="666984766" X-IronPort-AV: E=Sophos;i="5.96,143,1665471600"; d="scan'208";a="666984766" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.176.133]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2022 16:08:13 -0800 Date: Sun, 06 Nov 2022 16:08:12 -0800 Message-ID: <87tu3blj83.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Andi Shyti Subject: Re: [Intel-gfx] [PATCH v5 5/7] drm/i915/gt: Create per-tile RC6 sysfs interface In-Reply-To: References: <20220217144158.21555-1-andi.shyti@linux.intel.com> <20220217144158.21555-6-andi.shyti@linux.intel.com> <12c2fcf8-ef3b-e59c-fe1e-23bc8f12cfe5@linux.intel.com> <164518120389.6218.14670990912373168491@jlahtine-mobl.ger.corp.intel.com> <02fe43a4-0cb5-54e3-cd2f-b4bc128e7161@linux.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=ISO-8859-7 Content-Transfer-Encoding: quoted-printable 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: , Cc: Tvrtko Ursulin , Intel GFX , Lucas De Marchi , DRI Devel , Chris Wilson , lowren.h.lawson@intel.com, Matthew Auld Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Tue, 22 Feb 2022 00:57:02 -0800, Andi Shyti wrote: > Old thread, new comment below at the bottom. Please take a look. Thanks. > Hi Tvrtko and Joonas, > > > > > > > Now tiles have their own sysfs interfaces under the gt/ > > > > > > directory. Because RC6 is a property that can be configured on a > > > > > > tile basis, then each tile should have its own interface > > > > > > > > > > > > The new sysfs structure will have a similar layout for the 4 ti= le > > > > > > case: > > > > > > > > > > > > /sys/.../card0 > > > > > > \u251c\u2500\u2500 gt > > > > > > \u2502=A0=A0 \u251c\u2500\u2500 gt0 > > > > > > \u2502=A0=A0 \u2502=A0=A0 \u251c\u2500\u2500 id > > > > > > \u2502=A0=A0 \u2502=A0=A0 \u251c\u2500\u2500 rc6_ena= ble > > > > > > \u2502=A0=A0 \u2502=A0=A0 \u251c\u2500\u2500 rc6_res= idency_ms > > > > > > . . . > > > > > > . . . > > > > > > . . > > > > > > \u2502=A0=A0 \u2514\u2500\u2500 gtN > > > > > > \u2502=A0=A0 \u251c\u2500\u2500 id > > > > > > \u2502=A0=A0 \u251c\u2500\u2500 rc6_enable > > > > > > \u2502=A0=A0 \u251c\u2500\u2500 rc6_residency_ms > > > > > > \u2502 . > > > > > > \u2502 . > > > > > > \u2502 > > > > > > \u2514\u2500\u2500 power/ -+ > > > > > > \u251c\u2500\u2500 rc6_enable | Origi= nal interface > > > > > > \u251c\u2500\u2500 rc6_residency_ms +-> kept = as existing ABI; > > > > > > . | it multiplexes over > > > > > > . | the GTs > > > > > > -+ > > > > > > > > > > > > The existing interfaces have been kept in their original locati= on > > > > > > to preserve the existing ABI. They act on all the GTs: when > > > > > > reading they provide the average value from all the GTs. > > > > > > > > > > Average feels very odd to me. I'd ask if we can get away providin= g an errno > > > > > instead? Or tile zero data? > > > > > > Tile zero data is always wrong, in my opinion. If we have round-robin > > > scaling workloads like some media cases, part of the system load might > > > just disappear when it goes to tile 1. > > > > I was thinking that in conjunction with deprecated log message it would= n't > > be wrong - I mean if the route take was to eventually retire the legacy > > files altogether. > > that's a good point... do we want to treat the legacy interfaces > as an error or do we want to make them a feature? As the > discussion is turning those interfaces are becoming a feature. > But what are we going to do with the coming interfaces? > > E.g. in the future we will have the rc6_enable/disable that can > be a command, so that we will add the "_store" interface per > tile. What are we going to do with the above interfaces? Are we > going to add a multiplexed command as well? > > > > When we have frequency readbacks without control, returning MAX() acr= oss > > > tiles would be the logical thing. The fact that parts of the hardware= can > > > be clocked lower when one part is fully utilized is the "new feature". > > > > > > After that we're only really left with the rc6_residency_ms. And that= is > > > the tough one. I'm inclined that MIN() across tiles would be the right > > > answer. If you are fully utilizing a single tile, you should be able = to > > > see it. > > > So we have MIN, AVG or SUM, or errno, or remove the file (which is > > just a different kind of errno?) to choose from. :) > > in this case it would just be MIN and MAX. At the end we have > here only two types of interface: frequencies and residency_ms. > For the first type we would use 'max', for the second 'min'. We have the comment below from Lowren about this about showing MAX for freq. Could someone reply. Thanks. On Sun, 06 Nov 2022 08:54:04 -0800, Lawson, Lowren H wrote: Why show maximum? Wouldn=A2t average be more accurate to the user experience? As a user, I expect the =A1card=A2 frequency to be relatively accurate to t= he entire card. If I see 1.6GHz, but the card is behaving as if it=A2s running a 1.0 & 1.6GHz on the different compute tiles, I=A2m going to see a massive decrease in compute workload performance while at =A1maximum=A2 frequency. 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 9B194C433FE for ; Mon, 7 Nov 2022 00:08:24 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id B957610E111; Mon, 7 Nov 2022 00:08:22 +0000 (UTC) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 2626110E111; Mon, 7 Nov 2022 00:08:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1667779700; x=1699315700; h=date:message-id:from:to:cc:subject:in-reply-to: references:mime-version:content-transfer-encoding; bh=9DOoUZdq46nHGydD6VuBdF2sql8gfDA2iF5/4kW1zkM=; b=GJ+HkhqI3ZaRF+0sBSa7OL+bjRm4wwdSkMMHOTGfwUm4RBi9ziZfqVKk XkUne5Ady9y74mrewSzLR4Px3dgTvsNwR5QkuV5VsjBmALC+xnyio2UAq 8kGEJ0Uojx8MN+Pa0/eghMZg9bYNSoJZNhPhTeqtcVIiLlQ2MScu22YuK niVdzuOtRP3AFB8AFyh2T74RbTP5b0ghoJ/AzDaQ25Vpp3r97LmADk/9W bnqeY3OgWr8WfCgl8Eyl1HBR6CHMiFEe7qlVkOA5w/LlGd+/PECHLcpWf VxZ49i9KRbrUSCH034B8b3wsn+vyOTW5/+yFmTxHD00wmaZdOZZ04nNMG Q==; X-IronPort-AV: E=McAfee;i="6500,9779,10523"; a="307917537" X-IronPort-AV: E=Sophos;i="5.96,143,1665471600"; d="scan'208";a="307917537" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2022 16:08:14 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10523"; a="666984766" X-IronPort-AV: E=Sophos;i="5.96,143,1665471600"; d="scan'208";a="666984766" Received: from adixit-mobl.amr.corp.intel.com (HELO adixit-arch.intel.com) ([10.212.176.133]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2022 16:08:13 -0800 Date: Sun, 06 Nov 2022 16:08:12 -0800 Message-ID: <87tu3blj83.wl-ashutosh.dixit@intel.com> From: "Dixit, Ashutosh" To: Andi Shyti In-Reply-To: References: <20220217144158.21555-1-andi.shyti@linux.intel.com> <20220217144158.21555-6-andi.shyti@linux.intel.com> <12c2fcf8-ef3b-e59c-fe1e-23bc8f12cfe5@linux.intel.com> <164518120389.6218.14670990912373168491@jlahtine-mobl.ger.corp.intel.com> <02fe43a4-0cb5-54e3-cd2f-b4bc128e7161@linux.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=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Subject: Re: [Intel-gfx] [PATCH v5 5/7] drm/i915/gt: Create per-tile RC6 sysfs interface X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Intel GFX , Lucas De Marchi , DRI Devel , Chris Wilson , lowren.h.lawson@intel.com, Matthew Auld Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, 22 Feb 2022 00:57:02 -0800, Andi Shyti wrote: > Old thread, new comment below at the bottom. Please take a look. Thanks. > Hi Tvrtko and Joonas, > > > > > > > Now tiles have their own sysfs interfaces under the gt/ > > > > > > directory. Because RC6 is a property that can be configured on a > > > > > > tile basis, then each tile should have its own interface > > > > > > > > > > > > The new sysfs structure will have a similar layout for the 4 ti= le > > > > > > case: > > > > > > > > > > > > /sys/.../card0 > > > > > > \u251c\u2500\u2500 gt > > > > > > \u2502=A0=A0 \u251c\u2500\u2500 gt0 > > > > > > \u2502=A0=A0 \u2502=A0=A0 \u251c\u2500\u2500 id > > > > > > \u2502=A0=A0 \u2502=A0=A0 \u251c\u2500\u2500 rc6_ena= ble > > > > > > \u2502=A0=A0 \u2502=A0=A0 \u251c\u2500\u2500 rc6_res= idency_ms > > > > > > . . . > > > > > > . . . > > > > > > . . > > > > > > \u2502=A0=A0 \u2514\u2500\u2500 gtN > > > > > > \u2502=A0=A0 \u251c\u2500\u2500 id > > > > > > \u2502=A0=A0 \u251c\u2500\u2500 rc6_enable > > > > > > \u2502=A0=A0 \u251c\u2500\u2500 rc6_residency_ms > > > > > > \u2502 . > > > > > > \u2502 . > > > > > > \u2502 > > > > > > \u2514\u2500\u2500 power/ -+ > > > > > > \u251c\u2500\u2500 rc6_enable | Origi= nal interface > > > > > > \u251c\u2500\u2500 rc6_residency_ms +-> kept = as existing ABI; > > > > > > . | it multiplexes over > > > > > > . | the GTs > > > > > > -+ > > > > > > > > > > > > The existing interfaces have been kept in their original locati= on > > > > > > to preserve the existing ABI. They act on all the GTs: when > > > > > > reading they provide the average value from all the GTs. > > > > > > > > > > Average feels very odd to me. I'd ask if we can get away providin= g an errno > > > > > instead? Or tile zero data? > > > > > > Tile zero data is always wrong, in my opinion. If we have round-robin > > > scaling workloads like some media cases, part of the system load might > > > just disappear when it goes to tile 1. > > > > I was thinking that in conjunction with deprecated log message it would= n't > > be wrong - I mean if the route take was to eventually retire the legacy > > files altogether. > > that's a good point... do we want to treat the legacy interfaces > as an error or do we want to make them a feature? As the > discussion is turning those interfaces are becoming a feature. > But what are we going to do with the coming interfaces? > > E.g. in the future we will have the rc6_enable/disable that can > be a command, so that we will add the "_store" interface per > tile. What are we going to do with the above interfaces? Are we > going to add a multiplexed command as well? > > > > When we have frequency readbacks without control, returning MAX() acr= oss > > > tiles would be the logical thing. The fact that parts of the hardware= can > > > be clocked lower when one part is fully utilized is the "new feature". > > > > > > After that we're only really left with the rc6_residency_ms. And that= is > > > the tough one. I'm inclined that MIN() across tiles would be the right > > > answer. If you are fully utilizing a single tile, you should be able = to > > > see it. > > > So we have MIN, AVG or SUM, or errno, or remove the file (which is > > just a different kind of errno?) to choose from. :) > > in this case it would just be MIN and MAX. At the end we have > here only two types of interface: frequencies and residency_ms. > For the first type we would use 'max', for the second 'min'. We have the comment below from Lowren about this about showing MAX for freq. Could someone reply. Thanks. On Sun, 06 Nov 2022 08:54:04 -0800, Lawson, Lowren H wrote: Why show maximum? Wouldn=A2t average be more accurate to the user experience? As a user, I expect the =A1card=A2 frequency to be relatively accurate to t= he entire card. If I see 1.6GHz, but the card is behaving as if it=A2s running a 1.0 & 1.6GHz on the different compute tiles, I=A2m going to see a massive decrease in compute workload performance while at =A1maximum=A2 frequency.