Song!
On Fri, Dec 02 2022 at 00:38, Song Liu wrote:
> Thanks for all these suggestions!
Welcome.
> On Thu, Dec 1, 2022 at 5:38 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote:
>> You have to be aware, that the rodata space needs to be page granular
>> while text and data can really aggregate below the page alignment, but
>> again might have different alignment requirements.
>
> I don't quite follow why rodata space needs to be page granular. If text can
> go below page granular, rodata should also do that, no?
Of course it can, except for the case of ro_after_init_data, because
that needs to be RW during module_init() and is then switched to RO when
module_init() returns success. So for that you need page granular maps
per module, right?
Sure you can have a separate space for rodata and ro_after_init_data,
but as I said to Mike:
"The point is, that rodata and ro_after_init_data is a pretty small
portion of modules as far as my limited analysis of a distro build
shows.
The bulk is in text and data. So if we preserve 2M pages for text and
for RW data and bite the bullet to split one 2M page for
ro[_after_init_]data, we get the maximum benefit for the least
complexity."
So under the assumption that rodata is small, it's questionable whether
the split of rodata and ro_after_init_data makes a lot of difference. It
might, but that needs to be investigated.
That's not a fundamental conceptual problem because adding a 4th type to
the concept we outlined so far is straight forward, right?
> I guess I will do my homework, and come back with as much information
> as possible for #1 + #2 + #3. Then, we can discuss whether it makes
> sense at all.
Correct. Please have a close look at the 11 architecture specific
module_alloc() variants so you can see what kind of tweaks and magic
they need, which lets you better specify the needs for the
initialization parameter set required.
> Does this sound like the right approach?
Very much so.
Thanks,
tglx
