Message ID | 20230912084044.955864-7-adrian.larumbe@collabora.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9ecd:0:b0:3f2:4152:657d with SMTP id t13csp401105vqx; Tue, 12 Sep 2023 06:18:41 -0700 (PDT) X-Google-Smtp-Source: AGHT+IH3/R3u9HdVMFh0X1iRSwpR/Rnx01CyFcFpGt5qtAvmyupIqsd5i77bN0d0gfVTERIF+AW6 X-Received: by 2002:a17:902:8202:b0:1c2:702:61af with SMTP id x2-20020a170902820200b001c2070261afmr10515365pln.38.1694524720290; Tue, 12 Sep 2023 06:18:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1694524720; cv=none; d=google.com; s=arc-20160816; b=dTkPAhZ70nu/fjRkC6cBWDpp8gNFI4myPJmtsg0yEzJZ2901PD0hU0IE0dHSFrZ2IJ OPSGJGuOQhzn0ex2YyOlmaKYcrOB7ECTESH95v7fnwzl7AI1fqG4+LNemeQMr4twLVZw Uh57tOAMISo/+lLRS57X2nMk1dJm/aHlp6fYO/Ec9wBYqCzkXQ7D+RxQadIrX9/xcoA4 SLYKzjYjkelxRHuNK6fo0UkhzSumcH7RAYX+9Hv2sY6biNwEbS/eH9rATtf1z0NCZKTa L/WAj+zPnCmAxol4mItemlkerg7pGgVLp6ameB+bB0Snl6mOSzuQn/ACzZOemim+Q9xb u3og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=wRbFxM+eWX43Z8buhIJQc47mL45OJsgXjTHtelHy8FE=; fh=FTgSgXNODyKPnkMLWI9rYUhDWD+RBdHVvNtucDUCZvw=; b=DwGAreNTvSP7wJmx98XFpBtTguVxn5yT8V5I91RWwGmXU+ProK59Y/ovqhfF4Qz7Gd HduBBCaHr1taArLO2R5mBPeINBLayhAouxmnQSub000h5EWriMxSluuoK7H/Bh7TMVAb bdnxq88kcYbvakLBc0sIJYZE50ne+AE6pTrFF3wVjEAv4AxS3S9Nk3SmCrgwep0rSluv Y+05jf574UPsGB1J2ytxdoKYOrMGzBVTrjdXEB/au0xn0ozDb5Ct+pP2K/Q39Hel0z9x 6o+bndAAcOu7DtWQYdcHtEg8oqf/J6iP+uYOySqpzbhsfFQdhqsGe8IIB0RBIWzVQFpJ ofLg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=lvSJjzxc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id l15-20020a170902f68f00b001bd9e2b4b46si8310413plg.601.2023.09.12.06.18.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Sep 2023 06:18:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=lvSJjzxc; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 2431D822B756; Tue, 12 Sep 2023 01:42:53 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232941AbjILImi (ORCPT <rfc822;pwkd43@gmail.com> + 38 others); Tue, 12 Sep 2023 04:42:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34984 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232955AbjILImN (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 12 Sep 2023 04:42:13 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 40BFE1704; Tue, 12 Sep 2023 01:40:58 -0700 (PDT) Received: from localhost.localdomain (unknown [IPv6:2a02:8010:65b5:0:1ac0:4dff:feee:236a]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: alarumbe) by madras.collabora.co.uk (Postfix) with ESMTPSA id 6C45E660732A; Tue, 12 Sep 2023 09:40:56 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1694508056; bh=0Ue2Nq3K4F+Ieb9zAp+RPvwDsQ7N3mlVuWGujSt9n9U=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=lvSJjzxc1ZmhnYwleAuh164cV0uUwzzl6vV5TH3j16K8fXZpmA7rEv0BWiGX7xWVb 78AEuLxGmmnxyLpKEBdwqUp9MUgJsj+6ZvnZK1qiAasHj8lL6Ps6SkBGfmFA1dnLOe aIYganw77fJYimILn74XWzlmk6vNaSvF9NzcsNko7k8c1XDvBw5Lcgw5cKkXung5qV Cq3t35tTf4aKLQ7uAy9V2nwRyROn5Nf2Ciw43ikqbu3sgbLOeAzlKOlxUTvgFBz5Sv rlfZEgYpfPP1eHqrG7ZUqtSPx8xMNSMOomNEzy5DpMmAyYAp8/qjuPcrAr3QXnLPYq Vyi/X5yFjwHyw== From: =?utf-8?q?Adri=C3=A1n_Larumbe?= <adrian.larumbe@collabora.com> To: maarten.lankhorst@linux.intel.com, mripard@kernel.org, tzimmermann@suse.de, airlied@gmail.com, daniel@ffwll.ch, robdclark@gmail.com, quic_abhinavk@quicinc.com, dmitry.baryshkov@linaro.org, sean@poorly.run, marijn.suijten@somainline.org, robh@kernel.org, steven.price@arm.com Cc: adrian.larumbe@collabora.com, dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org, freedreno@lists.freedesktop.org, healych@amazon.com, kernel@collabora.com Subject: [PATCH v4 6/6] drm/drm-file: Show finer-grained BO sizes in drm_show_memory_stats Date: Tue, 12 Sep 2023 09:37:00 +0100 Message-ID: <20230912084044.955864-7-adrian.larumbe@collabora.com> X-Mailer: git-send-email 2.42.0 In-Reply-To: <20230912084044.955864-1-adrian.larumbe@collabora.com> References: <20230912084044.955864-1-adrian.larumbe@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Tue, 12 Sep 2023 01:42:53 -0700 (PDT) X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1776835861864183225 X-GMAIL-MSGID: 1776837952972844752 |
Series |
Add fdinfo support to Panfrost
|
|
Commit Message
Adrián Larumbe
Sept. 12, 2023, 8:37 a.m. UTC
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 BO's whose size is
not a multiple of a MiB.
Fix it by changing the unit selection criteria.
For much bigger BO's, their size will naturally be aligned on something
bigger than a 4 KiB page, so in practice it is very unlikely their display
unit would default to KiB.
Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com>
---
drivers/gpu/drm/drm_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon <boris.brezillon@collabora.com> wrote: > > On Tue, 12 Sep 2023 09:37:00 +0100 > Adrián Larumbe <adrian.larumbe@collabora.com> 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 BO's whose size is > > not a multiple of a MiB. > > > > Fix it by changing the unit selection criteria. > > > > For much bigger BO's, their size will naturally be aligned on something > > bigger than a 4 KiB page, so in practice it is very unlikely their display > > unit would default to KiB. > > Let's wait for Rob's opinion on this. This would mean that if you have SZ_1G + SZ_1K worth of buffers, you'd report the result in KiB.. which seems like overkill to me, esp given that the result is just a snapshot in time of a figure that realistically is dynamic. Maybe if you have SZ_1G+SZ_1K worth of buffers you should report the result with more precision than GiB, but more than MiB seems a bit overkill. BR, -R > > > > Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> > > --- > > drivers/gpu/drm/drm_file.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > > index 762965e3d503..bf7d2fe46bfa 100644 > > --- a/drivers/gpu/drm/drm_file.c > > +++ b/drivers/gpu/drm/drm_file.c > > @@ -879,7 +879,7 @@ 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)) > > break; > > sz = div_u64(sz, SZ_1K); > > } >
On Tue, Sep 12, 2023 at 6:46 PM Rob Clark <robdclark@gmail.com> wrote: > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon > <boris.brezillon@collabora.com> wrote: > > > > On Tue, 12 Sep 2023 09:37:00 +0100 > > Adrián Larumbe <adrian.larumbe@collabora.com> 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 BO's whose size is > > > not a multiple of a MiB. > > > > > > Fix it by changing the unit selection criteria. > > > > > > For much bigger BO's, their size will naturally be aligned on something > > > bigger than a 4 KiB page, so in practice it is very unlikely their display > > > unit would default to KiB. > > > > Let's wait for Rob's opinion on this. > > This would mean that if you have SZ_1G + SZ_1K worth of buffers, you'd > report the result in KiB.. which seems like overkill to me, esp given > that the result is just a snapshot in time of a figure that > realistically is dynamic. > > Maybe if you have SZ_1G+SZ_1K worth of buffers you should report the > result with more precision than GiB, but more than MiB seems a bit > overkill. > > BR, > -R > > > > > > > Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> > > > --- > > > drivers/gpu/drm/drm_file.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > > > index 762965e3d503..bf7d2fe46bfa 100644 > > > --- a/drivers/gpu/drm/drm_file.c > > > +++ b/drivers/gpu/drm/drm_file.c > > > @@ -879,7 +879,7 @@ 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) btw, I was thinking more along the lines of: if (sz < 10*SZ_1K) (or perhaps maybe 100*SZ_1K) I mean, any visualization tool is going to scale the y axis based on the order of magnitude.. and if I'm looking at the fdinfo with my eyeballs I don't want to count the # of digits manually to do the conversion in my head. The difference btwn 4 or 5 or maybe 6 digits is easy enough to eyeball, but more than that is too much for my eyesight, and I'm not seeing how it is useful ;-) But if someone really has a valid use case for having precision in 1KB then I'm willing to be overruled. But I'm not a fan of the earlier approach of different drivers reporting results differently, the whole point of fdinfo was to have some standardized reporting. BR, -R > > > + if (sz & (SZ_1K - 1)) > > > break; > > > sz = div_u64(sz, SZ_1K); > > > } > >
On Tue, 12 Sep 2023 19:14:35 -0700 Rob Clark <robdclark@gmail.com> wrote: > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark <robdclark@gmail.com> wrote: > > > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon > > <boris.brezillon@collabora.com> wrote: > > > > > > On Tue, 12 Sep 2023 09:37:00 +0100 > > > Adrián Larumbe <adrian.larumbe@collabora.com> 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 BO's whose size is > > > > not a multiple of a MiB. > > > > > > > > Fix it by changing the unit selection criteria. > > > > > > > > For much bigger BO's, their size will naturally be aligned on something > > > > bigger than a 4 KiB page, so in practice it is very unlikely their display > > > > unit would default to KiB. > > > > > > Let's wait for Rob's opinion on this. > > > > This would mean that if you have SZ_1G + SZ_1K worth of buffers, you'd > > report the result in KiB.. which seems like overkill to me, esp given > > that the result is just a snapshot in time of a figure that > > realistically is dynamic. Yeah, my point was that, generally, such big buffers tend to have a bigger size alignment (like 2MB for anything bigger than 1GB), but maybe this assumption doesn't stand for all drivers. > > > > Maybe if you have SZ_1G+SZ_1K worth of buffers you should report the > > result with more precision than GiB, but more than MiB seems a bit > > overkill. > > > > BR, > > -R > > > > > > > > > > Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> > > > > --- > > > > drivers/gpu/drm/drm_file.c | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > > > > index 762965e3d503..bf7d2fe46bfa 100644 > > > > --- a/drivers/gpu/drm/drm_file.c > > > > +++ b/drivers/gpu/drm/drm_file.c > > > > @@ -879,7 +879,7 @@ 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) > > btw, I was thinking more along the lines of: > > if (sz < 10*SZ_1K) > > (or perhaps maybe 100*SZ_1K) I think I suggested doing that at some point: if ((sz & (SZ_1K - 1)) && sz < UPPER_UNIT_THRESHOLD * SZ_1K) break; so we can keep using the upper unit if the size is a multiple of this upper unit, even if it's smaller than the selected threshold. > > I mean, any visualization tool is going to scale the y axis based on > the order of magnitude.. and if I'm looking at the fdinfo with my > eyeballs I don't want to count the # of digits manually to do the > conversion in my head. The difference btwn 4 or 5 or maybe 6 digits > is easy enough to eyeball, but more than that is too much for my > eyesight, and I'm not seeing how it is useful ;-) > > But if someone really has a valid use case for having precision in 1KB > then I'm willing to be overruled. So, precision loss was one aspect, but my main concern was having things displayed in KiB when they could have been displayed in MiB, because the size is a multiple of a MiB but still not big enough to pass the threshold test (which was set to 10000x in the previous version). > But I'm not a fan of the earlier > approach of different drivers reporting results differently, the whole > point of fdinfo was to have some standardized reporting. Totally agree with that. > > BR, > -R > > > > > + if (sz & (SZ_1K - 1)) > > > > break; > > > > sz = div_u64(sz, SZ_1K); > > > > } > > >
On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon <boris.brezillon@collabora.com> wrote: > > On Tue, 12 Sep 2023 19:14:35 -0700 > Rob Clark <robdclark@gmail.com> wrote: > > > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark <robdclark@gmail.com> wrote: > > > > > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon > > > <boris.brezillon@collabora.com> wrote: > > > > > > > > On Tue, 12 Sep 2023 09:37:00 +0100 > > > > Adrián Larumbe <adrian.larumbe@collabora.com> 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 BO's whose size is > > > > > not a multiple of a MiB. > > > > > > > > > > Fix it by changing the unit selection criteria. > > > > > > > > > > For much bigger BO's, their size will naturally be aligned on something > > > > > bigger than a 4 KiB page, so in practice it is very unlikely their display > > > > > unit would default to KiB. > > > > > > > > Let's wait for Rob's opinion on this. > > > > > > This would mean that if you have SZ_1G + SZ_1K worth of buffers, you'd > > > report the result in KiB.. which seems like overkill to me, esp given > > > that the result is just a snapshot in time of a figure that > > > realistically is dynamic. > > Yeah, my point was that, generally, such big buffers tend to have > a bigger size alignment (like 2MB for anything bigger than 1GB), but > maybe this assumption doesn't stand for all drivers. Maybe for CMA? Regardless, this # is the sum of buffer sizes, so you could still get that 1G+1K scenario > > > > > > Maybe if you have SZ_1G+SZ_1K worth of buffers you should report the > > > result with more precision than GiB, but more than MiB seems a bit > > > overkill. > > > > > > BR, > > > -R > > > > > > > > > > > > > Signed-off-by: Adrián Larumbe <adrian.larumbe@collabora.com> > > > > > --- > > > > > drivers/gpu/drm/drm_file.c | 2 +- > > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c > > > > > index 762965e3d503..bf7d2fe46bfa 100644 > > > > > --- a/drivers/gpu/drm/drm_file.c > > > > > +++ b/drivers/gpu/drm/drm_file.c > > > > > @@ -879,7 +879,7 @@ 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) > > > > btw, I was thinking more along the lines of: > > > > if (sz < 10*SZ_1K) > > > > (or perhaps maybe 100*SZ_1K) > > I think I suggested doing that at some point: > > if ((sz & (SZ_1K - 1)) && > sz < UPPER_UNIT_THRESHOLD * SZ_1K) > break; > > so we can keep using the upper unit if the size is a multiple of this > upper unit, even if it's smaller than the selected threshold. yeah, that wfm BR, -R > > > > > I mean, any visualization tool is going to scale the y axis based on > > the order of magnitude.. and if I'm looking at the fdinfo with my > > eyeballs I don't want to count the # of digits manually to do the > > conversion in my head. The difference btwn 4 or 5 or maybe 6 digits > > is easy enough to eyeball, but more than that is too much for my > > eyesight, and I'm not seeing how it is useful ;-) > > > > But if someone really has a valid use case for having precision in 1KB > > then I'm willing to be overruled. > > So, precision loss was one aspect, but my main concern was having > things displayed in KiB when they could have been displayed in MiB, > because the size is a multiple of a MiB but still not big enough to > pass the threshold test (which was set to 10000x in the previous > version). > > > But I'm not a fan of the earlier > > approach of different drivers reporting results differently, the whole > > point of fdinfo was to have some standardized reporting. > > Totally agree with that. > > > > > BR, > > -R > > > > > > > + if (sz & (SZ_1K - 1)) > > > > > break; > > > > > sz = div_u64(sz, SZ_1K); > > > > > } > > > > >
On Wed, 13 Sep 2023 09:46:45 -0700 Rob Clark <robdclark@gmail.com> wrote: > On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon > <boris.brezillon@collabora.com> wrote: > > > > On Tue, 12 Sep 2023 19:14:35 -0700 > > Rob Clark <robdclark@gmail.com> wrote: > > > > > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark <robdclark@gmail.com> wrote: > > > > > > > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon > > > > <boris.brezillon@collabora.com> wrote: > > > > > > > > > > On Tue, 12 Sep 2023 09:37:00 +0100 > > > > > Adrián Larumbe <adrian.larumbe@collabora.com> 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 BO's whose size is > > > > > > not a multiple of a MiB. > > > > > > > > > > > > Fix it by changing the unit selection criteria. > > > > > > > > > > > > For much bigger BO's, their size will naturally be aligned on something > > > > > > bigger than a 4 KiB page, so in practice it is very unlikely their display > > > > > > unit would default to KiB. > > > > > > > > > > Let's wait for Rob's opinion on this. > > > > > > > > This would mean that if you have SZ_1G + SZ_1K worth of buffers, you'd > > > > report the result in KiB.. which seems like overkill to me, esp given > > > > that the result is just a snapshot in time of a figure that > > > > realistically is dynamic. > > > > Yeah, my point was that, generally, such big buffers tend to have > > a bigger size alignment (like 2MB for anything bigger than 1GB), but > > maybe this assumption doesn't stand for all drivers. > > Maybe for CMA? Regardless, this # is the sum of buffer sizes, so you > could still get that 1G+1K scenario My bad, for some reason I had per-buffer size printing in mind.
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c index 762965e3d503..bf7d2fe46bfa 100644 --- a/drivers/gpu/drm/drm_file.c +++ b/drivers/gpu/drm/drm_file.c @@ -879,7 +879,7 @@ 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)) break; sz = div_u64(sz, SZ_1K); }