Received: by 10.223.185.116 with SMTP id b49csp4449699wrg; Mon, 26 Feb 2018 18:41:16 -0800 (PST) X-Google-Smtp-Source: AH8x226i7mHqWS7dampDZV3oSH/pERq35U+qeudkGGRaG1GSttKx/k8qhKISwSv6rAnY1LemRsNq X-Received: by 10.99.113.94 with SMTP id b30mr10077686pgn.228.1519699276535; Mon, 26 Feb 2018 18:41:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519699276; cv=none; d=google.com; s=arc-20160816; b=i35jezoyKW5zN99nxOO8wleZIU2kQOpvO42ySGjsUfumlvc3ZVidgt6IdcZ/KEoBL3 wjsZRamDO0n/3p2kxgaauKJprC4xiD36+mXt0v/fE5UABXUU/y9V6d9VSVgcRENnYr5i TZ+JQ/94/ZCLELhZuqa8ZgQvup7hLQZNCmVk+p3qYAGTRJZ4St3UDZ6Pet8He2ilPQsL 7mEZhnu7OU0izki8K/YMsPe3h4PtwgHUf8NWCLXYM0QFTE48DFem5cVHmU2XdgUkLDgR MhVor1k0Jd71m73iMqIhueBpHpPzbtbEeiGTBnRENVs7G083cu3olsG/gAMwRccI/BcP geWQ== 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=Szmz/+LkuRe6Q16UqL1hRwUTD4g4vGY2ebVjvejt+Jk=; b=Bug4syTP9jgDpONmWylfViy5Vm/ZNna8Wdy+b9LRsiPVE8oWF4yAxq1PqkIS53fH7n KD+Wb5WD/rGrBFHZE9gpTtK85j4aSWOod1UoRBQPyxMnwbXCniPUdFsMJJ8piBg+9YUO 8zdCIXCWpk9rdJg6C4Q4IofacfM+Xxo0AsArqiRND+yMm4Zy3M6fowJERKhRnA3rMPzV Eb8GI6+koDIaD2TokVKCo974lwV2Jc2pjStRtfz7PvsLUiGbhFaV4UhJDguM75jw9u5p g0fON/YtmzYMK5re1yMp7Zf1BnF4yeWhmqoMkisWsfYAkv7pCTiyFg889QFWyDvOZKxb w5lw== 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 n59-v6si7678718plb.690.2018.02.26.18.41.01; Mon, 26 Feb 2018 18:41:16 -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 S1751718AbeB0CAC (ORCPT + 99 others); Mon, 26 Feb 2018 21:00:02 -0500 Received: from mga14.intel.com ([192.55.52.115]:29726 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634AbeB0CAB (ORCPT ); Mon, 26 Feb 2018 21:00:01 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 18:00:00 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,398,1515484800"; d="scan'208";a="178307447" Received: from aaronlu.sh.intel.com (HELO intel.com) ([10.239.159.135]) by orsmga004.jf.intel.com with ESMTP; 26 Feb 2018 17:59:57 -0800 Date: Tue, 27 Feb 2018 10:00:58 +0800 From: Aaron Lu To: David Rientjes Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Huang Ying , Dave Hansen , Kemi Wang , Tim Chen , Andi Kleen , Michal Hocko , Vlastimil Babka , Mel Gorman , Matthew Wilcox Subject: Re: [PATCH v3 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free Message-ID: <20180227020058.GB9141@intel.com> References: <20180226135346.7208-1-aaron.lu@intel.com> <20180226135346.7208-3-aaron.lu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Feb 26, 2018 at 01:53:10PM -0800, David Rientjes wrote: > On Mon, 26 Feb 2018, Aaron Lu wrote: > > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > > index 3154859cccd6..35576da0a6c9 100644 > > --- a/mm/page_alloc.c > > +++ b/mm/page_alloc.c > > @@ -1116,13 +1116,11 @@ static void free_pcppages_bulk(struct zone *zone, int count, > > int migratetype = 0; > > int batch_free = 0; > > bool isolated_pageblocks; > > + struct page *page, *tmp; > > + LIST_HEAD(head); > > > > pcp->count -= count; > > - spin_lock(&zone->lock); > > - isolated_pageblocks = has_isolate_pageblock(zone); > > - > > while (count) { > > - struct page *page; > > struct list_head *list; > > > > /* > > @@ -1144,26 +1142,31 @@ static void free_pcppages_bulk(struct zone *zone, int count, > > batch_free = count; > > > > do { > > - int mt; /* migratetype of the to-be-freed page */ > > - > > page = list_last_entry(list, struct page, lru); > > /* must delete as __free_one_page list manipulates */ > > Looks good in general, but I'm not sure how I reconcile this comment with > the new implementation that later links page->lru again. Thanks for pointing this out. I think the comment is useless now since there is a list_add_tail right below so it's obvious we need to take the page off its original list. I'll remove the comment in an update. > > > list_del(&page->lru); > > > > - mt = get_pcppage_migratetype(page); > > - /* MIGRATE_ISOLATE page should not go to pcplists */ > > - VM_BUG_ON_PAGE(is_migrate_isolate(mt), page); > > - /* Pageblock could have been isolated meanwhile */ > > - if (unlikely(isolated_pageblocks)) > > - mt = get_pageblock_migratetype(page); > > - > > if (bulkfree_pcp_prepare(page)) > > continue; > > > > - __free_one_page(page, page_to_pfn(page), zone, 0, mt); > > - trace_mm_page_pcpu_drain(page, 0, mt); > > + list_add_tail(&page->lru, &head); > > } while (--count && --batch_free && !list_empty(list)); > > }