From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756523AbdKQDrv (ORCPT ); Thu, 16 Nov 2017 22:47:51 -0500 Received: from mail-wm0-f41.google.com ([74.125.82.41]:42861 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756468AbdKQDrm (ORCPT ); Thu, 16 Nov 2017 22:47:42 -0500 X-Google-Smtp-Source: AGs4zMZ5H7XoJQt85iPdGLh7e4qd8N0ZIqqvPDU/TagUca8TGsuAS13Yb0aAms5b9Eq+4VHOR/7pg0JvEjuNv/zhNac= MIME-Version: 1.0 In-Reply-To: References: <20170817000548.32038-1-jglisse@redhat.com> <20170904155123.GA3161@redhat.com> <7026dfda-9fd0-2661-5efc-66063dfdf6bc@huawei.com> <20170905023826.GA4836@redhat.com> <20170905185414.GB24073@linux.intel.com> <0bc5047d-d27c-65b6-acab-921263e715c8@huawei.com> <20170906021216.GA23436@redhat.com> <4f4a2196-228d-5d54-5386-72c3ffb1481b@huawei.com> <1726639990.10465990.1504805251676.JavaMail.zimbra@redhat.com> <863afc77-ed84-fed5-ebb8-d88e636816a3@huawei.com> From: chetan L Date: Thu, 16 Nov 2017 19:47:40 -0800 Message-ID: Subject: Re: [HMM-v25 19/19] mm/hmm: add new helper to hotplug CDM memory region v3 To: Dan Williams Cc: Bob Liu , Jerome Glisse , Ross Zwisler , Andrew Morton , "linux-kernel@vger.kernel.org" , Linux MM , John Hubbard , David Nellans , Balbir Singh , majiuyue , "xieyisheng (A)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id vAH3m387016473 On Fri, Sep 8, 2017 at 1:43 PM, Dan Williams wrote: > On Thu, Sep 7, 2017 at 6:59 PM, Bob Liu wrote: >> On 2017/9/8 1:27, Jerome Glisse wrote: > [..] >>> No this are 2 orthogonal thing, they do not conflict with each others quite >>> the contrary. HMM (the CDM part is no different) is a set of helpers, see >>> it as a toolbox, for device driver. >>> >>> HMAT is a way for firmware to report memory resources with more informations >>> that just range of physical address. HMAT is specific to platform that rely >>> on ACPI. HMAT does not provide any helpers to manage these memory. >>> >>> So a device driver can get informations about device memory from HMAT and then >>> use HMM to help in managing and using this memory. >>> >> >> Yes, but as Balbir mentioned requires : >> 1. Don't online the memory as a NUMA node >> 2. Use the HMM-CDM API's to map the memory to ZONE DEVICE via the driver >> >> And I'm not sure whether Intel going to use this HMM-CDM based method for their "target domain" memory ? >> Or they prefer to NUMA approach? Ross？ Dan? > > The starting / strawman proposal for performance differentiated memory > ranges is to get platform firmware to mark them reserved by default. > Then, after we parse the HMAT, make them available via the device-dax > mechanism so that applications that need 100% guaranteed access to > these potentially high-value / limited-capacity ranges can be sure to > get them by default, i.e. before any random kernel objects are placed > in them. Otherwise, if there are no dedicated users for the memory > ranges via device-dax, or they don't need the total capacity, we want > to hotplug that memory into the general purpose memory allocator with > a numa node number so typical numactl and memory-management flows are > enabled. > > Ideally this would not be specific to HMAT and any agent that knows > differentiated performance characteristics of a memory range could use > this scheme. @Dan/Ross With this approach, in a SVM environment, if you would want a PRI(page grant) request to get satisfied from this HMAT-indexed memory node, then do you think we could make that happen. If yes, is that something you guys are currently working on. Chetan