Received: by 10.223.176.46 with SMTP id f43csp992345wra; Wed, 24 Jan 2018 08:58:50 -0800 (PST) X-Google-Smtp-Source: AH8x227KA2f3qW9sGfUyO2A2Y1XrkzrZNp69YrZXNuIyKuGPjJaYoNEUqKyA59XmcCqU79RxITf3 X-Received: by 2002:a17:902:868f:: with SMTP id g15-v6mr6173139plo.137.1516813130608; Wed, 24 Jan 2018 08:58:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516813130; cv=none; d=google.com; s=arc-20160816; b=mX2syvQ0bqUvGdWwgZo8+s+9yYfRaiNVgimtvZ9ulO3B7Wnk9Qw02f9ZbL2vlzC0JF 3icMX0XtaFrFgKEVWd6hDz53pPbjn9L/WlTLxl3w4w9GMtcfUL+zlXGeqrMQfMH/Ifwc iox5uEc9a+x3oaUDrx6Ar7DVFaheNlQalVl7xw6vrPzhwxOKc6KiAfwFbEueQOQLPRWO cVyQCZgPMHRsLYaNrdTn/73ftElKTA5xb40/Frxtt9HYMeQY9IW0Ur5HweNjxGHVkaVo DHQtyeH6DW6PZ8/HTRhNNzBgo4OIWiN30wdv6eIjfZAviCWHiNUY0JXY8QQfPGCJ9XTb LCZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:arc-authentication-results; bh=IkbprNspcaSYuooD5/hU14/lYYYRNji1fC3ep2Z3+fI=; b=Ezohx1RWtuMYi7HPjx1LPPXBOgD2mdHcmdQ6+nOZmtc8e3pdNE8O6xJvh2p++ruhkQ qfUW9/ABZU4EeplkBLx4LRxOJZb5RB76TCwA7sNXtRzywf7UjBqRSGLjKnnaUU3ef+zV f10WPsAeGfoJkqNLQi77b538YS1H8+ORndPQ7VMKT/wLx698NwioJSPahW+1MK3+m4zr abUb5NuFQaL41q3iLj5XOZJXenhH9gR8j9iCS0qOnCAiTkR3HcZaJDPZP1Bzxw3oaboH wcxAUrrJYeMennTy+FZJx5XEimhvDSgGpeoChmJnxxP75cOaJTEtjT8MNFQ7laZw6YDm 6NNQ== 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 88-v6si473370ple.76.2018.01.24.08.58.36; Wed, 24 Jan 2018 08:58:50 -0800 (PST) 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 S934395AbeAXQ5u (ORCPT + 99 others); Wed, 24 Jan 2018 11:57:50 -0500 Received: from mga01.intel.com ([192.55.52.88]:29122 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934301AbeAXQ5s (ORCPT ); Wed, 24 Jan 2018 11:57:48 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2018 08:57:43 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,408,1511856000"; d="scan'208";a="26021894" Received: from ray.jf.intel.com (HELO [10.7.201.133]) ([10.7.201.133]) by orsmga001.jf.intel.com with ESMTP; 24 Jan 2018 08:57:43 -0800 Subject: Re: [PATCH 2/2] free_pcppages_bulk: prefetch buddy while not holding lock To: Mel Gorman , Aaron Lu References: <20180124023050.20097-1-aaron.lu@intel.com> <20180124023050.20097-2-aaron.lu@intel.com> <20180124164344.lca63gjn7mefuiac@techsingularity.net> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Huang Ying , Kemi Wang , Tim Chen , Andi Kleen , Michal Hocko , Vlastimil Babka From: Dave Hansen Message-ID: <148a42d8-8306-2f2f-7f7c-86bc118f8ccd@intel.com> Date: Wed, 24 Jan 2018 08:57:43 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20180124164344.lca63gjn7mefuiac@techsingularity.net> Content-Type: text/plain; charset=iso-8859-15 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 01/24/2018 08:43 AM, Mel Gorman wrote: > I'm less convinced by this for a microbenchmark. Prefetch has not been a > universal win in the past and we cannot be sure that it's a good idea on > all architectures or doesn't have other side-effects such as consuming > memory bandwidth for data we don't need or evicting cache hot data for > buddy information that is not used. I had the same reaction. But, I think this case is special. We *always* do buddy merging (well, before the next patch in the series is applied) and check an order-0 page's buddy to try to merge it when it goes into the main allocator. So, the cacheline will always come in. IOW, I don't think this has the same downsides normally associated with prefetch() since the data is always used.