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