Re: [PATCH] mm/pdx: Add comments throughout the codebase for pdx

[Jan Beulich <jbeulich@xxxxxxxx>]

On 22.06.2023 14:39, Alejandro Vallejo wrote:
> On Thu, Jun 22, 2023 at 11:15:17AM +0200, Jan Beulich wrote:
>>>>> + * This is a technique to avoid wasting memory on machines known to have
>>>>> + * split their machine address space in two big discontinuous and highly
>>>>> + * disjoint chunks.
>>>>
>>>> Why two? There can be any number, and in fact on the system I originally
>>>> had data from for reference (when first writing this code) iirc there
>>>> were 8 nodes, each with a chunk of memory far away from the other chunks.
>>>> The compression scheme used merely requires that some "inner" bits are
>>>> unused (always zero) in all of those ranges.
>>> Well, our implementation only supports two and I didn't see any obvious
>>> hints about intending to increasing that number.
>>
>> Where are you taking that "supports two" from? When I first wrote this code,
>> it was tested against a system with 8 (maybe it was 4, but certainly more
>> than 2) discontiguous regions (not counting the hole below 4G).
> You can have any number, but there's a single contiguous bit slice being
> removed, as far as I can see. The adaptor functions in
> xen/include/xen/pdx.h perform a single shift.
> 
>     static inline unsigned long pfn_to_pdx(unsigned long pfn)
>     {
>         return (pfn & pfn_pdx_bottom_mask) |
>                ((pfn & pfn_top_mask) >> pfn_pdx_hole_shift);
>     }
> 
>     static inline unsigned long pdx_to_pfn(unsigned long pdx)
>     {
>         return (pdx & pfn_pdx_bottom_mask) |
>                ((pdx << pfn_pdx_hole_shift) & pfn_top_mask);
>     }
> 
> Unless I'm missing some non-obvious piece of the puzzle, I'd say that for a
> truly general compressor we'd need some kind of loop over the hole mask.

Well, further compression might be possible that way, yes, but that's
entirely orthogonal to the number of discontiguous regions we're
talking about. Consider

0x0000100000000000-0x00001000ffffffff
0x0000200000000000-0x00002000ffffffff
0x0000300000000000-0x00003000ffffffff
0x0000400000000000-0x00004000ffffffff

The reference system's arrangement was slightly more complex (first and
foremost because of the memory below 4G that node 0 had), but came close
to the above conceptually.

Jan