On Mon, Apr 25, 2016 at 11:33:15AM +0200, Vlastimil Babka wrote:
> On 04/15/2016 10:58 AM, Mel Gorman wrote:
> >order-0 pages by definition cannot be compound so avoid the check in the
> >fast path for those pages.
> >
> >Signed-off-by: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx>
>
> Acked-by: Vlastimil Babka <vbabka@xxxxxxx>
>
> Suggestion to improve below:
>
> >---
> > mm/page_alloc.c | 25 +++++++++++++++++--------
> > 1 file changed, 17 insertions(+), 8 deletions(-)
> >
> >diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >index 59de90d5d3a3..5d205bcfe10d 100644
> >--- a/mm/page_alloc.c
> >+++ b/mm/page_alloc.c
> >@@ -1024,24 +1024,33 @@ void __meminit reserve_bootmem_region(unsigned long start, unsigned long end)
> >
> > static bool free_pages_prepare(struct page *page, unsigned int order)
> > {
> >- bool compound = PageCompound(page);
> >- int i, bad = 0;
> >+ int bad = 0;
> >
> > VM_BUG_ON_PAGE(PageTail(page), page);
> >- VM_BUG_ON_PAGE(compound && compound_order(page) != order, page);
> >
> > trace_mm_page_free(page, order);
> > kmemcheck_free_shadow(page, order);
> > kasan_free_pages(page, order);
> >
> >+ /*
> >+ * Check tail pages before head page information is cleared to
> >+ * avoid checking PageCompound for order-0 pages.
> >+ */
> >+ if (order) {
>
> Sticking unlikely() here results in:
>
> add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-30 (-30)
> function old new delta
> free_pages_prepare 771 741 -30
>
> And from brief comparison of disassembly it really seems it's moved the
> compound handling towards the end of the function, which should be nicer for
> the instruction cache, branch prediction etc. And since this series is about
> microoptimization, I think the extra step is worth it.
>
I dithered on this a bit and could not convince myself that the order
case really is unlikely. It depends on the situation as we could be
tearing down a large THP-backed mapping. SLUB is also using compound
pages so it's both workload and configuration dependent whether this
path is really likely or not.
--
Mel Gorman
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>