Re: [PATCH] mm/page_alloc: make sure __rmqueue() etc. always inline

2017-10-18 Thread Aaron Lu
On Wed, Oct 18, 2017 at 08:28:56AM +0200, Vlastimil Babka wrote: > On 10/18/2017 03:53 AM, Lu, Aaron wrote: > > On Tue, 2017-10-17 at 13:32 +0200, Vlastimil Babka wrote: > >> With gcc 7.2.1: > >>> ./scripts/bloat-o-meter base.o mm/page_alloc.o > >> > >> add/remove: 1/2 grow/shrink: 2/0 up/down: 249

Re: [PATCH] mm/page_alloc: make sure __rmqueue() etc. always inline

2017-10-17 Thread Vlastimil Babka
On 10/18/2017 03:53 AM, Lu, Aaron wrote: > On Tue, 2017-10-17 at 13:32 +0200, Vlastimil Babka wrote: >> >> Are transparent hugepages enabled? If yes, __rmqueue() is called from >> rmqueue(), and there's only one page fault (and __rmqueue()) per 512 >> "writes to each page". If not, __rmqueue() is c

Re: [PATCH] mm/page_alloc: make sure __rmqueue() etc. always inline

2017-10-17 Thread Lu, Aaron
On Tue, 2017-10-17 at 13:32 +0200, Vlastimil Babka wrote: > On 10/13/2017 08:31 AM, Aaron Lu wrote: > > __rmqueue(), __rmqueue_fallback(), __rmqueue_smallest() and > > __rmqueue_cma_fallback() are all in page allocator's hot path and > > better be finished as soon as possible. One way to make them

Re: [PATCH] mm/page_alloc: make sure __rmqueue() etc. always inline

2017-10-17 Thread Vlastimil Babka
On 10/13/2017 08:31 AM, Aaron Lu wrote: > __rmqueue(), __rmqueue_fallback(), __rmqueue_smallest() and > __rmqueue_cma_fallback() are all in page allocator's hot path and > better be finished as soon as possible. One way to make them faster > is by making them inline. But as Andrew Morton and Andi K

[PATCH] mm/page_alloc: make sure __rmqueue() etc. always inline

2017-10-12 Thread Aaron Lu
__rmqueue(), __rmqueue_fallback(), __rmqueue_smallest() and __rmqueue_cma_fallback() are all in page allocator's hot path and better be finished as soon as possible. One way to make them faster is by making them inline. But as Andrew Morton and Andi Kleen pointed out: https://lkml.org/lkml/2017/10/