Le 07/12/2022 à 22:04, Thomas Gleixner a écrit :
> Christophe,
>
> On Wed, Dec 07 2022 at 16:53, Christophe Leroy wrote:
>> Le 07/12/2022 à 16:36, Thomas Gleixner a écrit :
>>> The "use free space in existing mappings" mechanism is not required to
>>> be PMD_SIZE based, right?
>
> Correct. I just used it for the example.
>
>>> Large page size, strict separation:
>>>
>>> struct mod_alloc_type_params {
>>> [MOD_ALLOC_TYPE_TEXT] = {
>>> .mapto_type = MOD_ALLOC_TYPE_TEXT,
>>> .flags = FLAG_SHARED_PMD | FLAG_SECOND_ADDRESS_SPACE,
>>> .granularity = PMD_SIZE,
>>> .alignment = MOD_ARCH_ALIGNMENT,
>>> .start[0] = MODULES_VADDR,
>>> .end[0] = MODULES_END,
>>> .start[1] = MODULES_VADDR_2ND,
>>> .end[1] = MODULES_END_2ND,
>>> .pgprot = PAGE_KERNEL_EXEC,
>>> .fill = text_poke,
>>> .invalidate = text_poke_invalidate,
>>> },
>>
>> Don't restrict implementation to PMD_SIZE only.
>>
>> On powerpc 8xx:
>> - PMD_SIZE is 4 Mbytes
>> - Large pages are 512 kbytes and 8 Mbytes.
>>
>> It even has large pages of size 16 kbytes when build for 4k normal page
>> size.
>
> @granularity takes any size which is valid from the architecture side
> and can handle the @pgprot distinctions.
>
> That's why I separated functionality and configuration.
>
> Note, it's not strict compile time configuration. You can either build
> it completely dynamic at boot or have a static configuration structure
> as compile time default.
>
> That static default might be __initconst for architectures where there
> is no boot time detection and change required, but can be __initdata for
> those which need to adjust it to the needs of the detected CPU/platform
> before feeding it into the module allocator init function.
>
> Does that answer your question?
>
Yes it does, thanks.
Christophe
