Received: by 10.223.185.116 with SMTP id b49csp8808999wrg; Fri, 2 Mar 2018 08:17:49 -0800 (PST) X-Google-Smtp-Source: AG47ELtdZIT5gV7ZieKu3aJydq1boavvjnBG5MztB2tOHYlmFsnjINWl7WC9Nb5GIIZyOL0yFJUT X-Received: by 10.99.141.200 with SMTP id z191mr4898088pgd.418.1520007469672; Fri, 02 Mar 2018 08:17:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520007469; cv=none; d=google.com; s=arc-20160816; b=IGZVu+yA1dwR6gE6Df8LEmYUjVOx47/6Vo0jb4sqU+zEVrYvGrIcrB21l3AEh2CC6f 90mPzCpKtFxFHhz4/47Hg9UMP+dDICfEeh4+GOLrSUTQl+31aLbp3fBBdp3sXZfD0/J7 xVbwLG0eQCjnhJcsqmGyzCBYPB9gHerP7p6iTalt2yW9hxWJjpflY6rR5r9HIpHqh3by zFqHTEooOFAM3N8kEVkw9rWDwQemoeX+p360PDAkolTiofeh/xOsaUj91kAr0nG8DRXI 3+tjmVe65nlBmgY9lqsuMr6lox+o0p5rswfGJ70X+0tkzeyoxzxe0LN2SDprlPmSRB/n VUYA== 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=Pm355/5+HHY6ktL8ZB6SM4PP/NbB8Ue8BMNINaMiGFs=; b=037vI/I4cQr0gy2zyIAS7FIHKdwEGGXKGO7aAfUNGUqZCmQ39rY+kKFOj5s5QRTwD1 EC8P/RzkpPkswjAgF5flzcawJXtI+GskYyzqaACmDf+aH2knVyTuBTFvRfLHIz+jXuIv coOZUF0aiOGATEqofIh1DTyBOIu9y63Ww24smyj3WlY+I4PvlGue4QTDuVjVU9TJAvUr G2mwLWRZ4rjkot9DAa92Ca9fwbh+FDL52059s+hptnlFzzTOYA5bgmeg4j2vhcNJWX4C UuQmrDFp5v8MF3SxH4qPICinld5kUu30rYJobfcCWIfuer/14IikJhKVQ92CqV89mfdP 7VMw== 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 y5-v6si4878036plr.350.2018.03.02.08.17.34; Fri, 02 Mar 2018 08:17:49 -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 S1424100AbeCBPeI (ORCPT + 99 others); Fri, 2 Mar 2018 10:34:08 -0500 Received: from mga11.intel.com ([192.55.52.93]:38783 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1423376AbeCBPeD (ORCPT ); Fri, 2 Mar 2018 10:34:03 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Mar 2018 07:34:03 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.47,412,1515484800"; d="scan'208";a="205024748" Received: from jskanche-mobl.amr.corp.intel.com (HELO [10.252.134.197]) ([10.252.134.197]) by orsmga005.jf.intel.com with ESMTP; 02 Mar 2018 07:34:02 -0800 Subject: Re: [PATCH v4 2/3] mm/free_pcppages_bulk: do not hold lock when picking pages to free To: Aaron Lu , Michal Hocko References: <20180301062845.26038-1-aaron.lu@intel.com> <20180301062845.26038-3-aaron.lu@intel.com> <20180301135518.GJ15057@dhcp22.suse.cz> <20180302071533.GA6356@intel.com> Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Huang Ying , Kemi Wang , Tim Chen , Andi Kleen , Vlastimil Babka , Mel Gorman , Matthew Wilcox , David Rientjes From: Dave Hansen Message-ID: Date: Fri, 2 Mar 2018 07:34:01 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180302071533.GA6356@intel.com> Content-Type: text/plain; charset=utf-8 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 03/01/2018 11:15 PM, Aaron Lu wrote: > >> I am still quite surprised that this would have such a large impact. > Most likely due to the cachelines for these page structures are warmed > up outside of zone->lock. The workload here is a pretty tight microbenchmark and single biggest bottleneck is cache misses on 'struct page'. It's not memory bandwidth bound. So, anything you can give the CPU keep it fed and not waiting on cache misses will be a win. There's never going to be a real-world workload that sees this kind of increase, but the change in the micro isn't super-surprising because it so directly targets the bottleneck.