From: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
To: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>,
Andi Shyti <andi.shyti@linux.intel.com>
Cc: Intel GFX <intel-gfx@lists.freedesktop.org>,
Lucas De Marchi <lucas.demarchi@intel.com>,
Matthew Auld <matthew.auld@intel.com>,
DRI Devel <dri-devel@lists.freedesktop.org>,
Chris Wilson <chris@chris-wilson.co.uk>
Subject: Re: [Intel-gfx] [PATCH v5 5/7] drm/i915/gt: Create per-tile RC6 sysfs interface
Date: Mon, 21 Feb 2022 17:12:23 +0000 [thread overview]
Message-ID: <02fe43a4-0cb5-54e3-cd2f-b4bc128e7161@linux.intel.com> (raw)
In-Reply-To: <164518120389.6218.14670990912373168491@jlahtine-mobl.ger.corp.intel.com>
On 18/02/2022 10:46, Joonas Lahtinen wrote:
> Quoting Andi Shyti (2022-02-17 17:53:58)
>> Hi Tvrtko,
>>
>>>> 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 tile
>>>> case:
>>>>
>>>> /sys/.../card0
>>>> \u251c\u2500\u2500 gt
>>>> \u2502 \u251c\u2500\u2500 gt0
>>>> \u2502 \u2502 \u251c\u2500\u2500 id
>>>> \u2502 \u2502 \u251c\u2500\u2500 rc6_enable
>>>> \u2502 \u2502 \u251c\u2500\u2500 rc6_residency_ms
>>>> . . .
>>>> . . .
>>>> . .
>>>> \u2502 \u2514\u2500\u2500 gtN
>>>> \u2502 \u251c\u2500\u2500 id
>>>> \u2502 \u251c\u2500\u2500 rc6_enable
>>>> \u2502 \u251c\u2500\u2500 rc6_residency_ms
>>>> \u2502 .
>>>> \u2502 .
>>>> \u2502
>>>> \u2514\u2500\u2500 power/ -+
>>>> \u251c\u2500\u2500 rc6_enable | Original 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 location
>>>> 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 providing 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
wouldn't be wrong - I mean if the route take was to eventually retire
the legacy files altogether.
>> Real multiplexing would be providing something when reading and
>> when writing. The idea of average came while revieweing with
>> Chris the write multiplexing. Indeed it makes sense to provide
>> some common value, but I don't know how useful it can be to the
>> user (still if the user needs any average).
>
> I think all read/write controls like min/max/boost_freq should return
> an error from the global interface if all the tiles don't return same
> value. Write will always overwrite per-tile values.
That would work I think, if the option chosen was not to retire the
legacy files.
> When we have frequency readbacks without control, returning MAX() across
> 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. :)
Regards,
Tvrtko
> This all would be what feels natural for an user who has their setup
> tuned for single-tile device. And would allow simple round-robing
> balancing across the tiles in somewhat coherent manner.
next prev parent reply other threads:[~2022-02-21 17:12 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-17 14:41 [Intel-gfx] [PATCH v5 0/7] Introduce multitile support Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 1/7] drm/i915: Rename INTEL_REGION_LMEM with INTEL_REGION_LMEM_0 Andi Shyti
2022-02-28 19:53 ` Michal Wajdeczko
2022-03-01 15:19 ` Andrzej Hajda
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 2/7] drm/i915: Prepare for multiple GTs Andi Shyti
2022-03-01 15:15 ` Andrzej Hajda
2022-03-06 19:20 ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 3/7] drm/i915/gt: add gt_is_root() helper Andi Shyti
2022-02-28 20:02 ` Michal Wajdeczko
2022-03-01 15:25 ` Andrzej Hajda
2022-03-06 19:23 ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 4/7] drm/i915/gt: create per-tile sysfs interface Andi Shyti
2022-03-02 16:57 ` Andrzej Hajda
2022-03-06 23:04 ` Andi Shyti
2022-03-07 20:25 ` Andrzej Hajda
2022-03-13 19:45 ` Andi Shyti
2022-03-13 21:30 ` Andi Shyti
2022-03-14 12:08 ` Andrzej Hajda
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 5/7] drm/i915/gt: Create per-tile RC6 " Andi Shyti
2022-02-17 15:34 ` Tvrtko Ursulin
2022-02-17 15:53 ` Andi Shyti
2022-02-18 9:12 ` Tvrtko Ursulin
2022-02-18 9:21 ` Andi Shyti
2022-02-18 10:46 ` Joonas Lahtinen
2022-02-21 17:12 ` Tvrtko Ursulin [this message]
2022-02-22 8:57 ` Andi Shyti
2022-11-07 0:08 ` Dixit, Ashutosh
2022-02-17 20:49 ` kernel test robot
2022-02-17 23:53 ` kernel test robot
2022-03-03 10:19 ` Andrzej Hajda
2022-03-13 22:15 ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 6/7] drm/i915/gt: Create per-tile RPS sysfs interfaces Andi Shyti
2022-02-17 19:47 ` kernel test robot
2022-03-03 10:55 ` Andrzej Hajda
2022-03-13 23:09 ` Andi Shyti
2022-02-17 14:41 ` [Intel-gfx] [PATCH v5 7/7] drm/i915/gt: Adding new sysfs frequency attributes Andi Shyti
2022-02-17 15:45 ` Andi Shyti
2022-02-17 17:06 ` Sundaresan, Sujaritha
2022-02-28 20:37 ` Michal Wajdeczko
2022-03-14 0:38 ` Andi Shyti
2022-03-14 1:32 ` Sundaresan, Sujaritha
2022-03-03 11:17 ` Andrzej Hajda
2022-02-17 23:12 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce multitile support Patchwork
2022-02-17 23:13 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2022-02-17 23:40 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2022-02-17 23:40 ` [Intel-gfx] ✗ Fi.CI.BUILD: warning " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=02fe43a4-0cb5-54e3-cd2f-b4bc128e7161@linux.intel.com \
--to=tvrtko.ursulin@linux.intel.com \
--cc=andi.shyti@linux.intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=joonas.lahtinen@linux.intel.com \
--cc=lucas.demarchi@intel.com \
--cc=matthew.auld@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox