On Wed, Aug 14, 2024 at 11:45 AM David Hildenbrand <david@xxxxxxxxxx> wrote: > > On 14.08.24 06:10, Mateusz Guzik wrote: > > On Wed, Aug 14, 2024 at 5:02 AM Yin Fengwei <fengwei.yin@xxxxxxxxx> wrote: > >> > >> On 8/13/24 03:14, Mateusz Guzik wrote: > >>> would you mind benchmarking the change which merely force-inlines _compund_page? > >>> > >>> https://lore.kernel.org/linux-mm/66c4fcc5-47f6-438c-a73a-3af6e19c3200@xxxxxxxxxx/ > >> This change can resolve the regression also: > > > > Great, thanks. > > > > David, I guess this means it would be fine to inline the entire thing > > at least from this bench standpoint. Given that this is your idea I > > guess you should do the needful(tm)? :) > > Testing > > diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h > index 5769fe6e4950..25e25b34f4a0 100644 > --- a/include/linux/page-flags.h > +++ b/include/linux/page-flags.h > @@ -235,7 +235,7 @@ static __always_inline int page_is_fake_head(const struct page *page) > return page_fixed_fake_head(page) != page; > } > > -static inline unsigned long _compound_head(const struct page *page) > +static __always_inline unsigned long _compound_head(const struct page *page) > { > unsigned long head = READ_ONCE(page->compound_head); > > > With a kernel-config based on something derived from Fedora > config-6.8.9-100.fc38.x86_64 for convenience with > > CONFIG_HUGETLB_PAGE_OPTIMIZE_VMEMMAP=y > > add/remove: 15/14 grow/shrink: 79/87 up/down: 12836/-13917 (-1081) [snip] > Total: Before=32786363, After=32785282, chg -0.00% I guess there should be no opposition then? Given that this is your patch I presume you are going to see this through. I don't want any mention or cc on the patch, thanks for understanding :) -- Mateusz Guzik <mjguzik gmail.com>
