Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp8358049imu; Fri, 28 Dec 2018 16:24:36 -0800 (PST) X-Google-Smtp-Source: ALg8bN4xsOe3yDMKgy7qkg5OEXbeGkFfxD4ahGnwjXrVW0zwSwuYq9pKUbfGWERkutyrek0kinix X-Received: by 2002:a17:902:8d95:: with SMTP id v21mr29479102plo.162.1546043076929; Fri, 28 Dec 2018 16:24:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546043076; cv=none; d=google.com; s=arc-20160816; b=p9l5pUQd2PbH93tYzZ9Vm9CrVbnkfeTGndUay8iI2X0INPIKieub0DIVFyrRkSuq+1 CrNyG3siP5/G6ByxyuaZRZyHw+TX+oS4LiA/lxYKPeqhXYrSS2DohY7O/qHVDkXyKuyH EF6XV1vjzCCb4M91Oa6vrv6YcbW9yDpIEkceT+bH9tUy0pGMQdW2FdLVh2RHDv+xRtEN EHEDRl1zNw5wMu0fpzx2PGHDjA25GeYF97sKFrDCX/MCh7Yeu42b3AmDmgj1x85kZXxS owwoUNijAJuIHhKhaGNbWWgxmWANHvCuJZZpPuqJGHT3TV7cW+NyIknCQeRFamUvMCa0 EIaQ== 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=yVkbOx/kzbPCu9/DHsvxr9NV1yI9PcGeX7A6CmvePHU=; b=ISobe7Po5qgAheo0B2TZL1L/JCfvsUCWXlSoZKu1//TB+Onkc1T0ZzVeZbtaAqCc/D I3uR6xTU9IqcG360P+NGWtR7ZtG25R/HGH42RISOukZPVNMNfTY2ddeZaLgXUcdETtTf Qfhq/knyJB3cZXbvtwWMFySwqTU9/yeGIF/dm7qeFrfTJzAx1I2tcwKlH6Zw/S0OfJqn mb+IGrH4AnJLDN18jbTK1eNhYs97JdeRaPfC90GOIm/glfKOT/vK5mwS0hLZqQmYzHTQ gY2KAkhZt6rkzLRjaR2Ro4rTAtFTdo59/Ch2sfLwBFqfMggfV4JLNYXKrxSRfie1EPyr 9Pfg== 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=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r28si37562936pgm.317.2018.12.28.16.24.20; Fri, 28 Dec 2018 16:24: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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731626AbeL1MWi (ORCPT + 99 others); Fri, 28 Dec 2018 07:22:38 -0500 Received: from mx2.suse.de ([195.135.220.15]:46524 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1731789AbeL1MPR (ORCPT ); Fri, 28 Dec 2018 07:15:17 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3E00FAF3D; Fri, 28 Dec 2018 12:15:16 +0000 (UTC) Date: Fri, 28 Dec 2018 13:15:15 +0100 From: Michal Hocko To: Fengguang Wu Cc: Andrew Morton , Linux Memory Management List , kvm@vger.kernel.org, LKML , Fan Du , Yao Yuan , Peng Dong , Huang Ying , Liu Jingqi , Dong Eddie , Dave Hansen , Zhang Yi , Dan Williams Subject: Re: [RFC][PATCH v2 00/21] PMEM NUMA node and hotness accounting/migration Message-ID: <20181228121515.GS16738@dhcp22.suse.cz> References: <20181226131446.330864849@intel.com> <20181227203158.GO16738@dhcp22.suse.cz> <20181228050806.ewpxtwo3fpw7h3lq@wfg-t540p.sh.intel.com> <20181228084105.GQ16738@dhcp22.suse.cz> <20181228094208.7lgxhha34zpqu4db@wfg-t540p.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181228094208.7lgxhha34zpqu4db@wfg-t540p.sh.intel.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 28-12-18 17:42:08, Wu Fengguang wrote: [...] > Those look unnecessary complexities for this post. This v2 patchset > mainly fulfills our first milestone goal: a minimal viable solution > that's relatively clean to backport. Even when preparing for new > upstreamable versions, it may be good to keep it simple for the > initial upstream inclusion. On the other hand this is creating a new NUMA semantic and I would like to have something long term thatn let's throw something in now and care about long term later. So I would really prefer to talk about long term plans first and only care about implementation details later. > > I haven't looked at the implementation yet but if you are proposing a > > special cased zone lists then this is something CDM (Coherent Device > > Memory) was trying to do two years ago and there was quite some > > skepticism in the approach. > > It looks we are pretty different than CDM. :) > We creating new NUMA nodes rather than CDM's new ZONE. > The zonelists modification is just to make PMEM nodes more separated. Yes, this is exactly what CDM was after. Have a zone which is not reachable without explicit request AFAIR. So no, I do not think you are too different, you just use a different terminology ;) -- Michal Hocko SUSE Labs