Re: [PATCH v2 0/8] pdx: introduce a new compression algorithm

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

On Wed, Jul 02, 2025 at 08:32:27AM +0200, Jan Beulich wrote:
> On 01.07.2025 22:46, Stefano Stabellini wrote:
> > On Tue, 1 Jul 2025, Jan Beulich wrote:
> >> Sadly from this you omitted the output from the setup of the offsets
> >> arrays. Considering also your later reply, I'd be curious to know what
> >> mfn_to_pdx(0x50000000) is.
> >  
> > Full logs here, and debug patch in attachment.
> > 
> > (XEN) Checking for initrd in /chosen
> > (XEN) RAM: 0000000000000000 - 000000007fffffff
> > (XEN) RAM: 0000000800000000 - 000000087fffffff
> > (XEN) RAM: 0000050000000000 - 000005007fffffff
> > (XEN) RAM: 0000060000000000 - 000006007fffffff
> > (XEN) RAM: 0000070000000000 - 000007007fffffff
> > (XEN) 
> > (XEN) MODULE[0]: 0000000022000000 - 0000000022172fff Xen         
> > (XEN) MODULE[1]: 0000000022200000 - 000000002220efff Device Tree 
> > (XEN) MODULE[2]: 0000000020400000 - 0000000021e2ffff Kernel      
> > (XEN)  RESVD[0]: 0000000000000000 - 0000000000ffffff
> > (XEN)  RESVD[1]: 0000000001000000 - 00000000015fffff
> > (XEN)  RESVD[2]: 0000000001600000 - 00000000017fffff
> > (XEN)  RESVD[3]: 0000000001800000 - 00000000097fffff
> > (XEN)  RESVD[4]: 0000000009800000 - 000000000bffffff
> > (XEN)  RESVD[5]: 0000000011126000 - 000000001114dfff
> > (XEN)  RESVD[6]: 000000001114e000 - 000000001214efff
> > (XEN)  RESVD[7]: 0000000017275000 - 000000001729cfff
> > (XEN)  RESVD[8]: 000000001729d000 - 000000001829dfff
> > (XEN)  RESVD[9]: 000000001a7df000 - 000000001a806fff
> > (XEN)  RESVD[10]: 000000001a807000 - 000000001b807fff
> > (XEN)  RESVD[11]: 000000001d908000 - 000000001d92ffff
> > (XEN)  RESVD[12]: 000000001d930000 - 000000001e930fff
> > (XEN)  RESVD[13]: 000000001829e000 - 000000001869dfff
> > (XEN)  RESVD[14]: 000000001869e000 - 00000000186ddfff
> > (XEN)  RESVD[15]: 0000000800000000 - 000000083fffffff
> > (XEN) 
> > (XEN) 
> > (XEN) Command line: console=dtuart dom0_mem=2048M console_timestamps=boot debug bootscrub=0 vwfi=native sched=null
> > (XEN) [00000006bfc302ec] parameter "debug" unknown!
> > (XEN) [00000006bfcc0476] DEBUG init_pdx 294 start=0 end=80000000
> > (XEN) [00000006bfcd2400] DEBUG init_pdx 294 start=800000000 end=880000000
> > (XEN) [00000006bfce29ec] DEBUG init_pdx 294 start=50000000000 end=50080000000
> > (XEN) [00000006bfcf1768] DEBUG init_pdx 294 start=60000000000 end=60080000000
> > (XEN) [00000006bfd015a4] DEBUG init_pdx 294 start=70000000000 end=70080000000
> > (XEN) [00000006bfd1444f] DEBUG setup_mm 252
> 
> This one is immediately after init_pdx(), i.e. by here the log messages from
> Roger's patch (out of pfn_pdx_compression_setup()) should have appeared.
> Which at least falsifies my earlier suspicion about there being an ordering
> issue. You do have PDX_OFFSET_COMPRESSION=y in your .config, don't you? Are
> we perhaps taking the only "return false" path in pfn_offset_sanitize_ranges()
> that doesn't issue a log message?

Sorry, should have posted this yesterday.  With the current offset
compression algorithm the memory map provided by Stefano is not
compressible, as the calculated PFN shift leads to lookup table
indexes that overflows the default table size.

I'm working on an improved version that attempts to always preserve
the most significant bits in the lookup table index, even if that
leads to merging regions.

Thanks, Roger.