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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.08.2023 18:06, Alejandro Vallejo wrote:
> An alt-patching series can probably make it very close to the perf win of
> this patch as long as it transforms the conversion hunks into no-ops when
> there's no hole. I looked into the 2018 patch, and I don't think it tried
> to go that far (afaics it's purpose is to inline the compression parameters
> into the code stream). I highly suspect it would still noticiably
> underperform compared to this one, but I admit it's guesswork and I'd be
> happy to be proven wrong through benchmarks.

The alt-patching certainly will have some residual overhead; if for nothing
else then for the long clobber lists in some of the alternatives.

> Summary:
>   * While alt-patching is an attractive alternative this series doesn't do
>     that and in the spirit of keeping things simple I'd really rather keep
>     it that way. Does this sound reasonable?
>   * For the topic of when to disable compression by default on x86, I
>     genuinely think now's as good a time as any. If we were to do it in 2
>     steps any project downstream may very well not notice until 2 releases
>     down the line, at which point they simply must turn compression back
>     on, which is what they would have to do now anyway.
>   * For the topic of allowing or not the option to be selectable, I think
>     it would be a mistake to preclude it because while we don't know of
>     physical memory maps with big holes on (publicly available) x86, Xen
>     may be itself virtualized with arbitrary memory maps. Unlikely and far
>     fetched as it is, it's IMO worth being at least cautious about. Gating
>     the feature on EXPERT=y and adding a big warning should be good enough
>     to avoid foot-shootouts.

I could live with this as a compromise; really my main objection is to not
allowing the functionality at all on x86. Beyond that I'm obviously not
overly happy with how things are moving here, but so be it.

Jan