On Thu, Mar 11, 2021 at 5:39 PM Michal Hocko [off-list ref] wrote:

On Thu 11-03-21 17:08:34, Muchun Song wrote:

quoted

On Thu, Mar 11, 2021 at 4:55 PM Michal Hocko [off-list ref] wrote:

quoted

On Thu 11-03-21 15:33:20, Muchun Song wrote:

quoted

On Wed, Mar 10, 2021 at 11:41 PM Michal Hocko [off-list ref] wrote:

quoted

On Mon 08-03-21 18:28:07, Muchun Song wrote:

quoted

When the "struct page size" crosses page boundaries we cannot
make use of this feature. Let free_vmemmap_pages_per_hpage()
return zero if that is the case, most of the functions can be
optimized away.

I am confused. Don't you check for this in early_hugetlb_free_vmemmap_param already?

Right.

quoted

Why do we need any runtime checks?

If the size of the struct page is not power of 2, compiler can think
is_hugetlb_free_vmemmap_enabled() always return false. So
the code snippet of this user can be optimized away.

E.g.

if (is_hugetlb_free_vmemmap_enabled())
        /* do something */

The compiler can drop "/* do something */" directly, because
it knows is_hugetlb_free_vmemmap_enabled() always returns
false.

OK, so this is a micro-optimization to generate a better code?

Right.

quoted

Is this measurable to warrant more code?

I have disassembled the code to confirm this behavior.
I know this is not the hot path. But it actually can decrease
the code size.

struct page which is not power of 2 is not a common case.

I know this is not a common case. But the check of
is_power_of_2(sizeof(struct page)) does not bring extra
runtime overhead. It just tells the compiler to optimize code
as much as possible.

Are you sure
it makes sense to micro optimize for an outliar. If you really want to
microptimize then do that for a common case - the feature being
disabled - via static key.

We cannot optimize the code size (vmlinux) even if we use a static
key when the size is not power of 2.

Sorry. I am confused why you disagree with this change.
It does not bring any disadvantages.

--
Michal Hocko
SUSE Labs