Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp203460pxb; Fri, 15 Jan 2021 00:38:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJzYAXvm4dnwK3IhluF99ra/YFpiGvSHYBdYbkdTfhWG2wO+uqfVn8hhb2lfB1+6SNk4Sxco X-Received: by 2002:a17:906:60c3:: with SMTP id f3mr7935805ejk.65.1610699893658; Fri, 15 Jan 2021 00:38:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610699893; cv=none; d=google.com; s=arc-20160816; b=xuCFGQfgVzRtrWifit9WCI1Z3aHZRIyownX/orVpH08akpBmKWR5J3W3ax/kzECK3Z hL80Kk5coYVdvzsozhV1ft+OTbm5x0tXBnG+esENOK8GOeJMcg6NGK7xFbK9mGgrE8gQ Zm0xkThFd8VBih2/8n+MY5mzZ3kuglUysvxPgAAmDVWrhI587R5702ifTew5JpVLwPIr 0YwNOutGpigJA6AdBwwH3IomYXq1pylWhWCyl29CCxUXVWsmhWbPedKoCNVC+ylo2SPT +hbrCU71JwDdCAJWNSRmzmOgxZI3WGzIqoMTFsI7nazTCb4r6yMS7pmnktLZjePg3PLI 35aA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :mime-version:user-agent:date:message-id:subject:from:cc:to :ironport-sdr:ironport-sdr; bh=hFmreNTJJXfn+ktH7lhAiYgXO7sgB0Sdl+7orrk2Z74=; b=ERjDtSiaz3C0sX1xLwF4rx69fMmY2srPK4++v22bJzb/KidEGGExtUoQ0Lnf4tV4d0 Xs1g9RGhh/p+pIBVtkbjgQxfkJ+IdWGd/1upfFpM7jTT/v3p3YJ5azT81E437N2khMlG zN7MVr1MTi+djKgp6JB0hwhZj9Cs3RABBut6TM1C+2zsXV1mseiWybZroKfAKYiczq0d 0A+NqNjR1Axb2QILpDZMP95nuUwgBtrmg2gNO8AgXUaQVnZ87NqITKu3UmXtQxZG3Ys/ MZAqk1S395DDRQJaMohOeANf+QlEflVT83wsxVTHlfavgsJpG6VRa3LB03/LjME0RYyD UySg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id n7si3025520ejz.740.2021.01.15.00.37.49; Fri, 15 Jan 2021 00:38:13 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731054AbhAOHZE (ORCPT + 99 others); Fri, 15 Jan 2021 02:25:04 -0500 Received: from mga01.intel.com ([192.55.52.88]:20855 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729451AbhAOHZD (ORCPT ); Fri, 15 Jan 2021 02:25:03 -0500 IronPort-SDR: 2mquRg54P9JbPGC5P7rmf3gH1t3R0pji7sUtatJ/VILf8BwTorXaDT+uUnfQF1mPguYiegD/xy 19YmTQ0zcQSQ== X-IronPort-AV: E=McAfee;i="6000,8403,9864"; a="197173954" X-IronPort-AV: E=Sophos;i="5.79,348,1602572400"; d="scan'208";a="197173954" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2021 23:23:11 -0800 IronPort-SDR: rI+g70nMjeju82zmMHGK73x/doUFYZSAe2vGJuYhomHwkIvTWuVo0O7Ct7zsxNcIwXaSIhdfNP DZ8veDKLVzNw== X-IronPort-AV: E=Sophos;i="5.79,348,1602572400"; d="scan'208";a="382568970" Received: from xingzhen-mobl.ccr.corp.intel.com (HELO [10.255.30.191]) ([10.255.30.191]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Jan 2021 23:23:10 -0800 To: linux-mm@kvack.org, LKML Cc: Dave Hansen , Tony , Tim C Chen , "Huang, Ying" , "Du, Julie" From: Xing Zhengjun Subject: Test report for kernel direct mapping performance Message-ID: <213b4567-46ce-f116-9cdf-bbd0c884eb3c@linux.intel.com> Date: Fri, 15 Jan 2021 15:23:07 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, There is currently a bit of a debate about the kernel direct map. Does using 2M/1G pages aggressively for the kernel direct map help performance? Or, is it an old optimization which is not as helpful on modern CPUs as it was in the old days? What is the penalty of a kernel feature that heavily demotes this mapping from larger to smaller pages? We did a set of runs with 1G and 2M pages enabled /disabled and saw the changes. [Conclusions] Assuming that this was a good representative set of workloads and that the data are good, for server usage, we conclude that the existing aggressive use of 1G mappings is a good choice since it represents the best in a plurality of the workloads. However, in a *majority* of cases, another mapping size (2M or 4k) potentially offers a performance improvement. This leads us to conclude that although 1G mappings are a good default choice, there is no compelling evidence that it must be the only choice, or that folks deriving benefits (like hardening) from smaller mapping sizes should avoid the smaller mapping sizes. [Summary of results] 1. The test was done on server platforms with 11 benchmarks. For the 4 different server platforms tested, each with three different maximums kernel mapping sizes: 4k, 2M, and 1G. Each system has enough memory to effectively deploy 1G mappings. For the 11 different benchmarks were used, not every benchmark was run on every system, there was a total of 259 tests. 2. For each benchmark/system combination, the 1G mapping had the highest performance for 45% of the tests, 2M for ~30%, and 4k for~20%. 3. From the average delta, among 1G/2M/4K, 4K gets the lowest performance in all the 4 test machines, while 1G gets the best performance on 2 test machines and 2M gets the best performance on the other 2 machines. 4. By testing with machine memory from 256G to 512G, we observed that the larger memory will lead to the performance better for 1G page size. With Large memory, Will-it-scale/vm-scalability/unixbench/reaim/hackbench shows 1G has the best performance, while kbuild/memtier/netperf shows 4K has the best performance. For more details please see the following web link: https://01.org/sites/default/files/documentation/test_report_for_kernel_direct_mapping_performance_0.pdf -- Zhengjun Xing