Received: by 10.223.176.5 with SMTP id f5csp2127870wra; Sun, 4 Feb 2018 21:30:36 -0800 (PST) X-Google-Smtp-Source: AH8x226MrqOMbfpzvjQzqo76snWWstkdswANzn1k1rRJoeiUk/F1O8dsCsncmzk1fHUKKAfPh+Bl X-Received: by 2002:a17:902:6ac7:: with SMTP id i7-v6mr41695801plt.368.1517808636547; Sun, 04 Feb 2018 21:30:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517808636; cv=none; d=google.com; s=arc-20160816; b=Yn9QhNC02yL/Omk8jssZboKeBHomII9YZ9F1sSVx9jjAk2lhDCMmNnO9u9hzqZk5bm DXheIIXg7PNWT/0dIhwY0dC+KE4QyQP71KWrQxclMisDl5gYUoj2HeUz8iV3lUr41h6D eZlC7w8rdokPNataVbHkDk5APvisJ5hN5eVZ+oGDT/tRm/boPT84FQALwMsu6JuuRo0N u10xB3wskDTRjU30MZlFuV50ZWdIMypVEZ9Vhz6HAYA6pNf/P1X2f+EVp6VMTe3tyIC9 Jm2Oq2JQq7R70t71cCmMzDox8XdZyLWg2nJL76qnbmp4osq36K3BUAyj3JultcYkN62K a+DQ== 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:message-id:subject:cc:to:from:date :arc-authentication-results; bh=gNYrATufdQPFRnCP0cffE3UNMcddC39liKWBHc1zmRI=; b=aMfUIVJN2X2BVfmRGx+2VSUY1UDbrfAeUphTZ1z6DamDIvSy88CP2bGn9HO/fPtjO6 wS8w2GegU+cCeN3YLXmYX0W+xWrB7jVhCK/EJmh1re6am5KTBJeABWnYXwVZGGjscuN3 8mtZrElQh36JBakJTXZ7/8ABMHHOCrUYly7vAY2X3mYVAVh+kCglQnz0eAsimO3gaRE9 SGFHGbG5FHyTyUhYlIuHrZEWCR+sRRKdha7qpql71BtOaYSKVaIEZkDSWCFk5WYHAuIU E8XisZV7/sMQb+nAMNp/Wd0mBzax7823ztMNscCXbuxqBjq8dC5hhEwojwuslvSUjcDf mKHg== 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 w12-v6si1861014pld.162.2018.02.04.21.30.21; Sun, 04 Feb 2018 21:30:36 -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 S1752478AbeBEF3i (ORCPT + 99 others); Mon, 5 Feb 2018 00:29:38 -0500 Received: from mga05.intel.com ([192.55.52.43]:41306 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750861AbeBEF3b (ORCPT ); Mon, 5 Feb 2018 00:29:31 -0500 X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga002.jf.intel.com ([10.7.209.21]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2018 21:29:31 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,463,1511856000"; d="scan'208";a="31995893" Received: from aaronlu.sh.intel.com (HELO intel.com) ([10.239.159.135]) by orsmga002.jf.intel.com with ESMTP; 04 Feb 2018 21:29:29 -0800 Date: Mon, 5 Feb 2018 13:30:13 +0800 From: Aaron Lu To: linux-mm@kvack.org, linux-kernel@vger.kernel.org Cc: Andrew Morton , Huang Ying , Dave Hansen , Kemi Wang , Tim Chen , Andi Kleen , Michal Hocko , Vlastimil Babka , Mel Gorman , Daniel Jordan Subject: RFC: eliminate zone->lock contention for will-it-scale/page_fault1 on big server Message-ID: <20180205053013.GB16980@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180124023050.20097-1-aaron.lu@intel.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In addition the the two patches, there are two more patches that I would like to get some feedback. The two patches are more radical: the 3rd deals with free path zone->lock contention by avoiding doing any merge for order0 pages while the 4th deals with allocation path zone->lock contention by taking pcp->batch pages off the free_area order0 list without the need to iterate the list. Both patches are developed based on "the most time consuming part of operations under zone->lock is cache misses on struct page". The 3rd patch may be controversial but doesn't have correctness problem; the 4th is in an early stage and serves only as a proof-of-concept. Your comments are appreciated, thanks.