Re: [PATCH 6/8] pdx: introduce a new compression algorithm based on offsets between regions

["Roger Pau Monné" <roger.pau@citrix.com>]

On Thu, Jun 12, 2025 at 09:26:25AM +0200, Roger Pau Monné wrote:
> On Wed, Jun 11, 2025 at 08:33:55PM +0100, Andrew Cooper wrote:
> > On 11/06/2025 6:16 pm, Roger Pau Monne wrote:
> > > We can discuss whether we want both the fast and the slow variants.  The
> > > slow (brute force) was added as a result of me playing with weird region
> > > layouts where the fast one didn't manage to compress, or the resulting
> > > coefficients had a poor compression ratio.  However at this point the
> > > slow variant has only proven helpful in synthetic cases, I haven't (yet?)
> > > seen a real host memory layout that would benefit from it.
> > 
> > I'm going to hold off on opinions until I've read the rest of the series.
> > 
> > One question through.  Can we round offset up to the next power of two,
> > so we can replace the divide with a shift?
> 
> I've tried to round up both offset and size, but that resulted in no
> compression in some cases.  I can try to maybe round just one of
> those?
> 
> Note that the divide is done once with offset and once with size,
> depending on the direction of the translation.  I can explore this a
> bit.

So for the 4s GNR example, rounding the offset to the nearest (lower)
power of two will result in:

PFN fast compression result diverge, expected:
 offset 0000063e80000 size 0000008300000 (91%)
got:
 offset 0000040000000 size 0000033e80000 (18%)
Ranges:
 0000000000000-0000008080000
 0000063e80000-000006be80000
 00000c7e80000-00000cfe80000
 000012be80000-0000133e80000

And that's just rounding the offset, if we then also round the size
there's no compression possible, as size would become 0x40000000 and
thus offset == size.

Thanks, Roger.