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

[Boris Brezillon]

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

> On Wed, Sep 13, 2023 at 12:36 AM Boris Brezillon
> <boris.brezillon at collabora.com> wrote:
> >
> > On Tue, 12 Sep 2023 19:14:35 -0700
> > Rob Clark <robdclark at gmail.com> wrote:
> >  
> > > On Tue, Sep 12, 2023 at 6:46 PM Rob Clark <robdclark at gmail.com> wrote:  
> > > >
> > > > On Tue, Sep 12, 2023 at 2:32 AM Boris Brezillon
> > > > <boris.brezillon at collabora.com> wrote:  
> > > > >
> > > > > On Tue, 12 Sep 2023 09:37:00 +0100
> > > > > Adrián Larumbe <adrian.larumbe at 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.