Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp19772img; Thu, 21 Mar 2019 13:05:49 -0700 (PDT) X-Google-Smtp-Source: APXvYqz1jwLrtiLz5cCsagLGXsk1CvKaMXuPPeDzy1inIbvSkKttEfYA9PYUGw2OoW6q9+2I4E47 X-Received: by 2002:a17:902:d894:: with SMTP id b20mr5470187plz.318.1553198749411; Thu, 21 Mar 2019 13:05:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553198749; cv=none; d=google.com; s=arc-20160816; b=RbamXbjB15WVG+3MJnht8V3RIniLb22lkC9tcOGUPsfYNBPJC0kHfiJilemq5VXVMP QdXucW4QyvI+BRozmenifRVvwD/DZ3pD9dCleF7inzqMHZPnlLNuJyFeFtsf70VEk0z8 g2GA3BLFTXjyBou7H2nwEqdfiwo0F6c7g+YsS1rEAnAsyJABvdP/HbFNQJKQA2FSTocX /0Et5DZDCX9JRbDWDO2HNkyinzHUiS8do8xwlHiuCIaJyCOnrBdFoJGRkzooVpff/62J W2GMj0nkzTcisRiM4If8zUGVU+KZ2T7+leD/Vzcv3atdMW7FngH3KyQLAnGjz8i60qyP wWDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=eCiD5gjvW3NVWsHXwQGeP5ZKsJarbf2O5NIyqu7kJU0=; b=W//5O15Ps/TRZ6HZVq5qLpqR8PL4X8wN705QBpQi+guQKo4PgzMQnqYu3LBuGQz9KG 5mLQu1EHMHvnIoYr2B2Q+CP2el+/aY933jGNAiHsY7pf1ydE637UN4OTyNQdkYXzV4+5 BJVB3FVtSM4jJ1Xuj8EtmBWDKKe42ZHcN6Da6NqzqUx8FzbL+GjHXmDFENqNMscztvzB pe4XPZB1OHPakJHRrwTZLOlT4EWEaRiFkGcQaHLNzl5lYF6tLO8OxMi/E6P5G23oJgTB +k/+VcFh9/UhSNLELqGpdIC29bIl9nUr2Zv/ivt31uWX1EozYqsVgNaOHCNjjiT9pk/8 fn2Q== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y7si4723666pfe.248.2019.03.21.13.05.31; Thu, 21 Mar 2019 13:05:49 -0700 (PDT) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728807AbfCUUC4 (ORCPT + 99 others); Thu, 21 Mar 2019 16:02:56 -0400 Received: from mga06.intel.com ([134.134.136.31]:5164 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728013AbfCUUC4 (ORCPT ); Thu, 21 Mar 2019 16:02:56 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Mar 2019 13:02:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,254,1549958400"; d="scan'208";a="309246228" Received: from unknown (HELO localhost.lm.intel.com) ([10.232.112.69]) by orsmga005.jf.intel.com with ESMTP; 21 Mar 2019 13:02:55 -0700 From: Keith Busch To: linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nvdimm@lists.01.org Cc: Dave Hansen , Dan Williams , Keith Busch Subject: [PATCH 0/5] Page demotion for memory reclaim Date: Thu, 21 Mar 2019 14:01:52 -0600 Message-Id: <20190321200157.29678-1-keith.busch@intel.com> X-Mailer: git-send-email 2.13.6 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The kernel has recently added support for using persistent memory as normal RAM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c221c0b0308fd01d9fb33a16f64d2fd95f8830a4 The persistent memory is hot added to nodes separate from other memory types, which makes it convenient to make node based memory policies. When persistent memory provides a larger and cheaper address space, but with slower access characteristics than system RAM, we'd like the kernel to make use of these memory-only nodes as a migration tier for pages that would normally be discared during memory reclaim. This is faster than doing IO for swap or page cache, and makes better utilization of available physical address space. The feature is not enabled by default. The user must opt-in to kernel managed page migration by defining the demotion path. In the future, we may want to have the kernel automatically create this based on heterogeneous memory attributes and CPU locality. Keith Busch (5): node: Define and export memory migration path mm: Split handling old page for migration mm: Attempt to migrate page in lieu of discard mm: Consider anonymous pages without swap mm/migrate: Add page movement trace event Documentation/ABI/stable/sysfs-devices-node | 11 +- drivers/base/node.c | 73 +++++++++++++ include/linux/migrate.h | 6 ++ include/linux/node.h | 6 ++ include/linux/swap.h | 20 ++++ include/trace/events/migrate.h | 29 ++++- mm/debug.c | 1 + mm/migrate.c | 161 ++++++++++++++++++---------- mm/vmscan.c | 25 ++++- 9 files changed, 271 insertions(+), 61 deletions(-) -- 2.14.4