On Thu, Mar 11, 2021 at 01:16:37PM +0100, Michal Hocko wrote: > On Thu 11-03-21 18:00:09, Muchun Song wrote: > [...] > > 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
