Re: [RFC v4 PATCH 3/5] mm/rmqueue_bulk: alloc without touching individual page structure

2018-10-22 Thread Aaron Lu
On Mon, Oct 22, 2018 at 11:37:53AM +0200, Vlastimil Babka wrote: > On 10/17/18 8:33 AM, Aaron Lu wrote: > > Profile on Intel Skylake server shows the most time consuming part > > under zone->lock on allocation path is accessing those to-be-returned > > page's "struct page" on the free_list inside z

Re: [RFC v4 PATCH 3/5] mm/rmqueue_bulk: alloc without touching individual page structure

2018-10-22 Thread Vlastimil Babka
On 10/17/18 8:33 AM, Aaron Lu wrote: > Profile on Intel Skylake server shows the most time consuming part > under zone->lock on allocation path is accessing those to-be-returned > page's "struct page" on the free_list inside zone->lock. One explanation > is, different CPUs are releasing pages to th

Re: [RFC v4 PATCH 3/5] mm/rmqueue_bulk: alloc without touching individual page structure

2018-10-18 Thread Aaron Lu
On Thu, Oct 18, 2018 at 12:20:55PM +0100, Mel Gorman wrote: > On Wed, Oct 17, 2018 at 10:23:27PM +0800, Aaron Lu wrote: > > > RT has had problems with cpu_relax in the past but more importantly, as > > > this delay for parallel compactions and allocations of contig ranges, > > > we could be stuck h

Re: [RFC v4 PATCH 3/5] mm/rmqueue_bulk: alloc without touching individual page structure

2018-10-18 Thread Mel Gorman
On Wed, Oct 17, 2018 at 10:23:27PM +0800, Aaron Lu wrote: > > RT has had problems with cpu_relax in the past but more importantly, as > > this delay for parallel compactions and allocations of contig ranges, > > we could be stuck here for very long periods of time with interrupts > > The longest p

Re: [RFC v4 PATCH 3/5] mm/rmqueue_bulk: alloc without touching individual page structure

2018-10-17 Thread Aaron Lu
On Wed, Oct 17, 2018 at 12:20:42PM +0100, Mel Gorman wrote: > On Wed, Oct 17, 2018 at 02:33:28PM +0800, Aaron Lu wrote: > > Profile on Intel Skylake server shows the most time consuming part > > under zone->lock on allocation path is accessing those to-be-returned > > page's "struct page" on the fr

Re: [RFC v4 PATCH 3/5] mm/rmqueue_bulk: alloc without touching individual page structure

2018-10-17 Thread Mel Gorman
On Wed, Oct 17, 2018 at 02:33:28PM +0800, Aaron Lu wrote: > Profile on Intel Skylake server shows the most time consuming part > under zone->lock on allocation path is accessing those to-be-returned > page's "struct page" on the free_list inside zone->lock. One explanation > is, different CPUs are

[RFC v4 PATCH 3/5] mm/rmqueue_bulk: alloc without touching individual page structure

2018-10-16 Thread Aaron Lu
Profile on Intel Skylake server shows the most time consuming part under zone->lock on allocation path is accessing those to-be-returned page's "struct page" on the free_list inside zone->lock. One explanation is, different CPUs are releasing pages to the head of free_list and those page's 'struct