linux-kernel - Re: [PATCH v4 6/6] drm/drm-file: Show finer-grained BO sizes in drm_show_memory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20230913191757.6594f8c8@collabora.com>
Date:   Wed, 13 Sep 2023 19:17:57 +0200
From:   Boris Brezillon <boris.brezillon@...labora.com>
To:     Rob Clark <robdclark@...il.com>
Cc:     Adrián Larumbe <adrian.larumbe@...labora.com>,
        maarten.lankhorst@...ux.intel.com, mripard@...nel.org,
        tzimmermann@...e.de, airlied@...il.com, daniel@...ll.ch,
        quic_abhinavk@...cinc.com, dmitry.baryshkov@...aro.org,
        sean@...rly.run, marijn.suijten@...ainline.org, robh@...nel.org,
        steven.price@....com, linux-arm-msm@...r.kernel.org,
        linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        healych@...zon.com, kernel@...labora.com,
        freedreno@...ts.freedesktop.org,
        Tvrtko Ursulin <tvrtko.ursulin@...ux.intel.com>
Subject: Re: [PATCH v4 6/6] drm/drm-file: Show finer-grained BO sizes in
 drm_show_memory_stats

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

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