Received: by 10.213.65.68 with SMTP id h4csp115743imn; Mon, 12 Mar 2018 20:38:46 -0700 (PDT) X-Google-Smtp-Source: AG47ELvN/iORr3mLcTvde/bOIOoZyVBdItggZACVg7M2dG2tcmD0fgWDsBsNoQTxbFTC7NHUQrki X-Received: by 10.101.97.79 with SMTP id o15mr8372004pgv.31.1520912325989; Mon, 12 Mar 2018 20:38:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520912325; cv=none; d=google.com; s=arc-20160816; b=inGlQ3rZfLMWBj05N0m7bhIyeAmxovCM4UKFdhfM7XNXL3rtqsCoVleWJ7MNlJSFqA I/er2AA+hiIFkYEZFTKD6kx2fKYwA9YNiWd+wGcYBXQBrX6ak/INLKlxs5XIB4Luq6PC mXwGF9DmD0onkEgg0ihoP7PbdORw3/rkftJFSQHAkZiVNy8tYZpCSdZRxq9CKokU1gzq tU0fDHif/VjZt3kz9N2yUF649BMTW8AS8UWTbVyZSRQcMMLSfLJ6OnXwKME5cU+SaMAl 41AXHWPJ8x9l99wAGdEnSABiRd1YSldRGLaGsNWKxL0a8XjxlM11AEBQXqVE0FKf3FXI i3wQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=TkH7GSo4Lf2eK2ZJQx99O0GX832XaTnUFkMHC1CwCss=; b=eyzc+9i2IADLT8HCtDilu2Mbt/ES6he6Ikp3ZL9lxeVWrn2iVVEDTWiiD28QDoGAU8 t6hiPLCI1O7vM5zKcFdydUG5Dvt3P+E1aEoA1QVq7Bl9ajeE7MKRStu42bd9iUBys4Hy PYecw2rSRCA4G22IJgO+4g+rLjty6Gbt+OVz3PZtAZh+IcXdOsvahgak177jpGUATkiy OB/QIZqXCzp0UjE8GqFGRBY678F8sKWrIXxCyUTydkSghf8M1166tuSql0uowKNkbW6Z JBlGkgGJ6PB25OUEn8QKH2+Hg+AxWQvfUA6RrAapMIva9iFH7eYQNCdxSrAbF98OLP8u e7sQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x15-v6si7203931plr.384.2018.03.12.20.38.01; Mon, 12 Mar 2018 20:38:45 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932594AbeCMDeR (ORCPT + 99 others); Mon, 12 Mar 2018 23:34:17 -0400 Received: from mga12.intel.com ([192.55.52.136]:22522 "EHLO mga12.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932294AbeCMDeQ (ORCPT ); Mon, 12 Mar 2018 23:34:16 -0400 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga106.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Mar 2018 20:34:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,463,1515484800"; d="scan'208";a="24674194" Received: from aaronlu.sh.intel.com (HELO intel.com) ([10.239.159.135]) by orsmga008.jf.intel.com with ESMTP; 12 Mar 2018 20:34:13 -0700 Date: Tue, 13 Mar 2018 11:35:19 +0800 From: Aaron Lu To: Dave Hansen Cc: Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huang Ying , Kemi Wang , Tim Chen , Andi Kleen , Michal Hocko , Vlastimil Babka , Mel Gorman , Matthew Wilcox , David Rientjes Subject: Re: [PATCH v4 3/3 update] mm/free_pcppages_bulk: prefetch buddy while not holding lock Message-ID: <20180313033519.GC13782@intel.com> References: <20180301062845.26038-1-aaron.lu@intel.com> <20180301062845.26038-4-aaron.lu@intel.com> <20180301160950.b561d6b8b561217bad511229@linux-foundation.org> <20180302082756.GC6356@intel.com> <20180309082431.GB30868@intel.com> <988ce376-bdc4-0989-5133-612bfa3f7c45@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <988ce376-bdc4-0989-5133-612bfa3f7c45@intel.com> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.