Thread (52 messages) 52 messages, 6 authors, 2021-03-12

Re: [External] Re: [PATCH v18 9/9] mm: hugetlb: optimize the code with the help of the compiler

From: Oscar Salvador <osalvador@suse.de>
Date: 2021-03-11 13:46:26
Also in: linux-fsdevel, linux-mm, lkml

On Thu, Mar 11, 2021 at 01:16:37PM +0100, Michal Hocko wrote:
On Thu 11-03-21 18:00:09, Muchun Song wrote:
[...]
quoted
Sorry. I am confused why you disagree with this change.
It does not bring any disadvantages.
Because it is adding a code which is not really necessary and which will
have to be maintained. Think of future changes which would need to grow
more of these. Hugetlb code paths shouldn't really think about size of
the struct page.
I have to confess that when I looked at the patch I found it nice in the way that
wipes out almost all clode dealing with vmemmap when sizeof(struct page) != power_of_2,
and I was convinced by the fact that only two places required the change.
So all in all it did not look like much churn, and not __that__ hard to maintain.

But I did not think in the case where this trick needs to be spread in more places
if the code changes over time.

So I agree that although it gets rid of a lot of code, it would seldomly pay off as
not many configuration out there are running on !power_of_2, and hugetlb is already
tricky enough.


-- 
Oscar Salvador
SUSE L3
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help