[PATCH v8] elf: Support THP segment load with madvise enabled THP

[Wilco Dijkstra]

Hi HJ,

> I changed it to
>
>      GL(dl_elf_thp_pagesize) = __get_thp_size ();
>      GL(dl_thp_mode) = __get_thp_mode ();
>      /* We cap the huge page size at MAX_THP_PAGESIZE to avoid
>         over-aligning on systems with very large normal pages
>         (like 64K pages with 512M huge pages).  */
>      if (GL(dl_elf_thp_pagesize) == 0
>          || GL(dl_elf_thp_pagesize) > MAX_THP_PAGESIZE
>          || GL(dl_thp_mode) == thp_mode_never
>          || GL(dl_thp_mode) == thp_mode_not_supported)
>        {
>          GL(dl_elf_thp_pagesize) = 0;
>          GL(dl_elf_thp_control) = 0;
>        }

That looks better - and the last part should reset dl_thp_mode too. Also we could
first read the mode and skip __get_thp_size if it is not always/madvise. The cost of
these calls is over 6000 cycles in a tight loop (~25000 cycles first time)...

> +/* After L has been mapped in, call madvise with MADV_HUGEPAGE if L is
> +   THP eligible.  */
> +
> +static inline void
> +_dl_postprocess_loadcmd_extra (struct link_map *l, const struct loadcmd *c)
> +{
> +  if (_dl_segment_thp_eligible (c, GL(dl_elf_thp_pagesize)))
>
> Why not do:
>
> if (GL(dl_thp_mode) == thp_mode_madvise

> This will be evaluated for every PT_LOAD segment.   With
> _dl_postprocess_loadcmd_extra_needed, it is evaluated only
> once in an object.

I don't believe evaluating GL(dl_thp_mode) is expensive, is it? It seems better to keep
the code simple and clean. We could save many thousands of cycles above - yet here
we're trying to save maybe 1-2 cycles via micro optimizations?

Cheers,
Wilco