Re: [PATCH 1/3] mm, page_alloc: un-inline the bad part of free_pages_check

[Vlastimil Babka]

On 04/27/2016 02:37 PM, Mel Gorman wrote:
> On Wed, Apr 27, 2016 at 02:01:14PM +0200, Vlastimil Babka wrote:
> > !DEBUG_VM bloat-o-meter:
> >
> > add/remove: 1/0 grow/shrink: 0/2 up/down: 124/-383 (-259)
> > function                                     old     new   delta
> > free_pages_check_bad                           -     124    +124
> > free_pcppages_bulk                          1509    1403    -106
> > __free_pages_ok                             1025     748    -277
> >
> > DEBUG_VM:
> >
> > add/remove: 1/0 grow/shrink: 0/1 up/down: 124/-242 (-118)
> > function                                     old     new   delta
> > free_pages_check_bad                           -     124    +124
> > free_pages_prepare                          1048     806    -242
> >
> > Signed-off-by: Vlastimil Babka <vbabka@xxxxxxx>
>
> This uninlines the check all right but it also introduces new function
> calls into the free path. As it's the free fast path, I suspect it would
> be a step in the wrong direction from a performance perspective.

Oh expected this to be a non-issue as the call only happens when a bad 
page is actually encountered, which is rare? But if you can measure some 
overhead here then sure.