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
usage.
The new selection criteria try to preserve precision, whilst also
increasing the display unit selection threshold to render more accurate
values.
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)
}
EXPORT_SYMBOL(drm_send_event);
+#define UPPER_UNIT_THRESHOLD 100
+
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)
break;
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
annoying.
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.
Regards,
Tvrtko
