[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180313033519.GC13782@intel.com>
Date: Tue, 13 Mar 2018 11:35:19 +0800
From: Aaron Lu <aaron.lu@...el.com>
To: Dave Hansen <dave.hansen@...el.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, Huang Ying <ying.huang@...el.com>,
Kemi Wang <kemi.wang@...el.com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Andi Kleen <ak@...ux.intel.com>,
Michal Hocko <mhocko@...e.com>,
Vlastimil Babka <vbabka@...e.cz>,
Mel Gorman <mgorman@...hsingularity.net>,
Matthew Wilcox <willy@...radead.org>,
David Rientjes <rientjes@...gle.com>
Subject: Re: [PATCH v4 3/3 update] mm/free_pcppages_bulk: prefetch buddy
while not holding lock
On Mon, Mar 12, 2018 at 10:32:32AM -0700, Dave Hansen wrote:
> On 03/09/2018 12:24 AM, Aaron Lu wrote:
> > + /*
> > + * We are going to put the page back to the global
> > + * pool, prefetch its buddy to speed up later access
> > + * under zone->lock. It is believed the overhead of
> > + * an additional test and calculating buddy_pfn here
> > + * can be offset by reduced memory latency later. To
> > + * avoid excessive prefetching due to large count, only
> > + * prefetch buddy for the last pcp->batch nr of pages.
> > + */
> > + if (count > pcp->batch)
> > + continue;
> > + pfn = page_to_pfn(page);
> > + buddy_pfn = __find_buddy_pfn(pfn, 0);
> > + buddy = page + (buddy_pfn - pfn);
> > + prefetch(buddy);
>
> FWIW, I think this needs to go into a helper function. Is that possible?
I'll give it a try.
>
> There's too much logic happening here. Also, 'count' going from
> batch_size->0 is totally non-obvious from the patch context. It makes
> this hunk look totally wrong by itself.
Powered by blists - more mailing lists