Re: [PATCH v2 5/5] pdx: Add CONFIG_HAS_PDX_COMPRESSION as a common Kconfig option

[Jan Beulich <jbeulich@xxxxxxxx>]

On 28.07.2023 18:58, Andrew Cooper wrote:
> On 28/07/2023 5:36 pm, Andrew Cooper wrote:
>> On 28/07/2023 8:59 am, Alejandro Vallejo wrote:
>>> Adds a new compile-time flag to allow disabling pdx compression and
>>> compiles out compression-related code/data. It also shorts the pdx<->pfn
>>> conversion macros and creates stubs for masking fucntions.
>>>
>>> While at it, removes the old arch-defined CONFIG_HAS_PDX flag, as it was
>>> not removable in practice.
>>>
>>> Signed-off-by: Alejandro Vallejo <alejandro.vallejo@xxxxxxxxx>
>>> ---
>>> v2:
>>>   * Merged v1/patch2: Removal of CONFIG_HAS_PDX here (Jan)
>> This series is now looking fine, except for the Kconfig aspect.
>>
>> This is not something any user or developer should ever be queried
>> about.  The feedback on the documentation patches alone show that it's
>> not understood well by the maintainers, even if the principle is accepted.
>>
>> There is never any reason to have this active on x86.

We can of course continue to disagree here. At least with EXPERT=y
selecting this option ought to remain possible for x86. Whether or
not the original systems this scheme was developed for ever went
public, such systems did (do) exist, and hence running Xen sensibly
on them (without losing all memory except that on node 0) ought to
be possible.

>  Indeed, Julien's
>> quick metric shows how much performance we waste by having it enabled.
> 
> Further to this, bloat-o-meter says net -30k of code and there are
> plenty of fastpaths getting a several cacheline reduction from this.

A similar reduction was achieved by the BMI2-alt-patching series I
had put together, yet you weren't willing to come to consensus on
it.

Jan