Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp3368530imu; Mon, 7 Jan 2019 01:59:41 -0800 (PST) X-Google-Smtp-Source: ALg8bN7NChMtY913mw3dh+d7zw0JMehfTCXIoTZKdp9vIM3ngkVdoARU12j6hNeqWm/ST5YxKHRo X-Received: by 2002:a17:902:1127:: with SMTP id d36mr59002150pla.299.1546855181802; Mon, 07 Jan 2019 01:59:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546855181; cv=none; d=google.com; s=arc-20160816; b=e79dqOAlVbv/hFXW39/fLW2FA7oLY7TfR/f+VqPj7rgr2fKmkE2ywFFV739/WD7Ota 4l0NIv62OTRyR4DqjE4Yc3xZl4GTJrsfw4FS2E/x2IR+2//0uhJp5ovvzIo/Z47QJHml xhbCHAi7/nx+SNSfpXlQoBLqgctGhXIzfcAPeyAk5Nf8ICLyfMrEGBoU5yAnGvcuc5Fj uIYCt3OOHTyVFq0u3S3xrrZpU1Oy66mK4+NnL/G5b9nED31Hj3QoWcFruG6VDWeIlaX8 FuKJ2ZFGNH3CHgAEO0sueSGwffhLridP2vtOI8aCl6KcHKIarncvU3eSIOHTDBbVIFXD b5LA== 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; bh=Lm7iOGrFUb1XYRXgpgSqV5Q+Vr0Kc8+ZVRL+7WdwNfY=; b=jyxXNpyRg31Zsj64A3crwSfeN4JXH/JzM84l9YZz08KkEXmbuaY/jXWXFbcBJjz5kQ PAd31JW9WhBqJjcgMZFXLINXxxY4Qn64vTmnwRNmyzJQTNfmokmtPKpal7LhtKk6gIf/ PEKFqpTIVVHqwSYPnhacIwWeGruAyurbosEMh0UkctXJ6d+3pjwcDClvYrMDreUqCojc Ff6MeKMb1HO9SPojRZkqPAVUEdQBP1fd/16Asl+nTd4YWy/ZZRfffHEKpX6AoMgej9OR abKgBHZTm1UqQU1q+sSWex+b9ez0AqO2C1BaHuvVuEW+nqixWDn3OhdwX+4rJI1PbnvJ hILw== 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 cb2si45692928plb.298.2019.01.07.01.59.26; Mon, 07 Jan 2019 01:59:41 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726819AbfAGJ56 (ORCPT + 99 others); Mon, 7 Jan 2019 04:57:58 -0500 Received: from mga06.intel.com ([134.134.136.31]:15279 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726485AbfAGJ55 (ORCPT ); Mon, 7 Jan 2019 04:57:57 -0500 X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga104.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Jan 2019 01:57:57 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.56,450,1539673200"; d="scan'208";a="116051963" Received: from tiwuxiex-mobl.ccr.corp.intel.com (HELO wfg-t570.sh.intel.com) ([10.254.213.147]) by orsmga003.jf.intel.com with ESMTP; 07 Jan 2019 01:57:54 -0800 Received: from wfg by wfg-t570.sh.intel.com with local (Exim 4.89) (envelope-from ) id 1ggRfN-00076b-8P; Mon, 07 Jan 2019 17:57:53 +0800 Date: Mon, 7 Jan 2019 17:57:53 +0800 From: Fengguang Wu To: "Aneesh Kumar K.V" Cc: Andrew Morton , Linux Memory Management List , Fan Du , kvm@vger.kernel.org, LKML , Yao Yuan , Peng Dong , Huang Ying , Liu Jingqi , Dong Eddie , Dave Hansen , Zhang Yi , Dan Williams Subject: Re: [RFC][PATCH v2 10/21] mm: build separate zonelist for PMEM and DRAM node Message-ID: <20190107095753.7feee5fxjja5lt75@wfg-t540p.sh.intel.com> References: <20181226131446.330864849@intel.com> <20181226133351.644607371@intel.com> <87sgyc7n9a.fsf@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <87sgyc7n9a.fsf@linux.ibm.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 01, 2019 at 02:44:41PM +0530, Aneesh Kumar K.V wrote: >Fengguang Wu writes: > >> From: Fan Du >> >> When allocate page, DRAM and PMEM node should better not fall back to >> each other. This allows migration code to explicitly control which type >> of node to allocate pages from. >> >> With this patch, PMEM NUMA node can only be used in 2 ways: >> - migrate in and out >> - numactl > >Can we achieve this using nodemask? That way we don't tag nodes with >different properties such as DRAM/PMEM. We can then give the >flexibilility to the device init code to add the new memory nodes to >the right nodemask Aneesh, in patch 2 we did create nodemask numa_nodes_pmem and numa_nodes_dram. What's your supposed way of "using nodemask"? Thanks, Fengguang