Re: [PATCH v3 0/4] Make PDX compression optional

[Jan Beulich <jbeulich@xxxxxxxx>]

On 16.08.2023 11:36, Alejandro Vallejo wrote:
> On Tue, Aug 08, 2023 at 02:02:16PM +0100, Alejandro Vallejo wrote:
>> Currently there's a CONFIG_HAS_PDX Kconfig option, but it's impossible to
>> disable it because the whole codebase performs unconditional
>> compression/decompression operations on addresses. This has the
>> unfortunate side effect that systems without a need for compression still
>> have to pay the performance impact of juggling bits on every pfn<->pdx
>> conversion (this requires reading several global variables). This series
>> attempts to:
>>
>>   * Leave the state of pdx and pdx compression documented
>>   * Factor out compression so it _can_ be removed through Kconfig
>>   * Make it so compression is disabled on x86 and enabled on both Aarch32
>>     and Aarch64 by default.
>>
>> Series summary:
>>
>> Patch 1 Moves hard-coded compression-related logic to helper functions
>> Patch 2 Refactors all instances of regions being validated for pdx
>>         compression conformance so it's done through a helper
>> Patch 3 Non-functional reorder in order to simplify the patch 8 diff
>> Patch 4 Adds new Kconfig option to compile out PDX compression and removes
>>         the old CONFIG_HAS_PDX, as it was non removable
>>
>> Already committed:
>>
>> v1/patch 1 documents the current general understanding of the pdx concept and
>>            pdx compression in particular
>> v1/patch 3 Marks the pdx compression globals as ro_after_init
>> v2/patch 1 Documents the differences between arm32 and arm64 directmaps
>>
>> Alejandro Vallejo (4):
>>   mm: Factor out the pdx compression logic in ma/va converters
>>   mm/pdx: Standardize region validation wrt pdx compression
>>   pdx: Reorder pdx.[ch]
>>   pdx: Add CONFIG_PDX_COMPRESSION as a common Kconfig option
> 
> @Jan: Just making sure, are you generally ok with this series as-is?

Well, okay would be too strong; I still don't see why my runtime patching
series isn't re-considered. But I don't mind it going in the way it is now.
I won't ack any part of it, though (in case that wasn't obvious), so it'll
be up to Andrew or Roger to supply the necessary x86 acks.

Jan