Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.36 as permitted sender) client-ip=23.128.96.36;
Date:   Wed, 13 Sep 2023 19:17:57 +0200
From:   Boris Brezillon <boris.brezillon@collabora.com>
To:     Rob Clark <robdclark@gmail.com>
Cc:     =?UTF-8?B?QWRyacOhbg==?= Larumbe <adrian.larumbe@collabora.com>,
        maarten.lankhorst@linux.intel.com, mripard@kernel.org,
        tzimmermann@suse.de, airlied@gmail.com, daniel@ffwll.ch,
        quic_abhinavk@quicinc.com, dmitry.baryshkov@linaro.org,
        sean@poorly.run, marijn.suijten@somainline.org, robh@kernel.org,
        steven.price@arm.com, linux-arm-msm@vger.kernel.org,
        linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
        healych@amazon.com, kernel@collabora.com,
        freedreno@lists.freedesktop.org,
        Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Subject: Re: [PATCH v4 6/6] drm/drm-file: Show finer-grained BO sizes in
 drm_show_memory_stats
Message-ID: <20230913191757.6594f8c8@collabora.com>
In-Reply-To: <CAF6AEGu+NeMfeP3yVLr76fUmXeWPx86D9ckw_WjXu+Xpn6DJvA@mail.gmail.com>
References: <20230912084044.955864-1-adrian.larumbe@collabora.com>
        <20230912084044.955864-7-adrian.larumbe@collabora.com>
        <20230912113210.65897aab@collabora.com>
        <CAF6AEGtzOS89V1vbobpSEb9KX8x9T0FfmkW2OAaxAKLs+GugKA@mail.gmail.com>
        <CAF6AEGup93tQMYrmx6iKex2Fxz+Yu5m-MMWPmeOQ4yx_Racnag@mail.gmail.com>
        <20230913093637.2748d217@collabora.com>
        <CAF6AEGu+NeMfeP3yVLr76fUmXeWPx86D9ckw_WjXu+Xpn6DJvA@mail.gmail.com>
Organization: Collabora
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Wed, 13 Sep 2023 09:46:45 -0700
Rob Clark <robdclark@gmail.com> wrote:

> On Wed, Sep 13, 2023 at 12:36=E2=80=AFAM Boris Brezillon
> <boris.brezillon@collabora.com> wrote:
> >
> > On Tue, 12 Sep 2023 19:14:35 -0700
> > Rob Clark <robdclark@gmail.com> wrote:
> > =20
> > > On Tue, Sep 12, 2023 at 6:46=E2=80=AFPM Rob Clark <robdclark@gmail.co=
m> wrote: =20
> > > >
> > > > On Tue, Sep 12, 2023 at 2:32=E2=80=AFAM Boris Brezillon
> > > > <boris.brezillon@collabora.com> wrote: =20
> > > > >
> > > > > On Tue, 12 Sep 2023 09:37:00 +0100
> > > > > Adri=C3=A1n Larumbe <adrian.larumbe@collabora.com> wrote:
> > > > > =20
> > > > > > The current implementation will try to pick the highest availab=
le 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 si=
ze 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 s=
omething
> > > > > > bigger than a 4 KiB page, so in practice it is very unlikely th=
eir display
> > > > > > unit would default to KiB. =20
> > > > >
> > > > > Let's wait for Rob's opinion on this. =20
> > > >
> > > > This would mean that if you have SZ_1G + SZ_1K worth of buffers, yo=
u'd
> > > > report the result in KiB.. which seems like overkill to me, esp giv=
en
> > > > that the result is just a snapshot in time of a figure that
> > > > realistically is dynamic. =20
> >
> > 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. =20
>=20
> 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.