Re: [PATCH v6 6/6] drm/drm-file: Show finer-grained BO sizes in drm_show_memory_stats

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On 22/09/2023 12:03, Adrián Larumbe wrote:
On 21.09.2023 11:14, Tvrtko Ursulin wrote:

On 20/09/2023 16:32, Tvrtko Ursulin wrote:

On 20/09/2023 00:34, Adrián Larumbe wrote:
The current implementation will try to pick the highest available size
display unit as soon as the BO size exceeds that of the previous
multiplier. That can lead to loss of precision in contexts of low memory

The new selection criteria try to preserve precision, whilst also
increasing the display unit selection threshold to render more accurate

Signed-off-by: Adrián Larumbe <adrian.larumbe@xxxxxxxxxxxxx>
Reviewed-by: Boris Brezillon <boris.brezillon@xxxxxxxxxxxxx>
Reviewed-by: Steven Price <steven.price@xxxxxxx>
   drivers/gpu/drm/drm_file.c | 5 ++++-
   1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 762965e3d503..34cfa128ffe5 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -872,6 +872,8 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
   static void print_size(struct drm_printer *p, const char *stat,
                  const char *region, u64 sz)
@@ -879,7 +881,8 @@ static void print_size(struct drm_printer *p,
const char *stat,
       unsigned u;
       for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
-        if (sz < SZ_1K)
+        if ((sz & (SZ_1K - 1)) &&

IS_ALIGNED worth it at all?

+            sz < UPPER_UNIT_THRESHOLD * SZ_1K)

Excuse me for a late comment (I was away). I did not get what what is
special about a ~10% threshold? Sounds to me just going with the lower
unit, when size is not aligned to the higher one, would be better than
sometimes precision-sometimes-not.

FWIW both current and the threshold option make testing the feature very

How so?

I have to build in the knowledge of implementation details of print_size() into my IGT in order to use the right size BOs, so test is able to verify stats move as expected. It just feels wrong.

So I'd really propose we simply use smaller unit when unaligned.

Like I said in the previous reply, for drm files whose overall BO size sum is enormous
but not a multiple of a MiB, this would render huge number representations in KiB.
I don't find this particularly comfortable to read, and then this extra precision
would mean nothing to nvtop or gputop, which would have to scale the size to their
available screen dimensions when plotting them.

I don't think numbers in KiB are so huge.

And I don't think people will end up reading them manually a lot anyway, since you have to hunt the pid, and fd, etc.. It is much more realistic that some tool like gputop will be used.

And I don't think consistency of units across drivers or whatever matters. Even better to keep userspace parser on their toes and make then follow drm-usage-stats.rst and not any implementations, at some point in time.



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux