From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by kanga.kvack.org (Postfix) with ESMTP id 09A636B0130 for ; Tue, 11 Nov 2014 14:01:25 -0500 (EST) Received: by mail-qc0-f182.google.com with SMTP id m20so8029275qcx.41 for ; Tue, 11 Nov 2014 11:01:24 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net. [2001:558:fe21:29:69:252:207:41]) by mx.google.com with ESMTPS id s2si38153826qar.44.2014.11.11.11.01.00 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 11 Nov 2014 11:01:21 -0800 (PST) Date: Tue, 11 Nov 2014 13:00:56 -0600 (CST) From: Christoph Lameter Subject: Re: HMM (heterogeneous memory management) v6 In-Reply-To: <1415644096-3513-1-git-send-email-j.glisse@gmail.com> Message-ID: References: <1415644096-3513-1-git-send-email-j.glisse@gmail.com> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: j.glisse@gmail.com Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Linus Torvalds , joro@8bytes.org, Mel Gorman , "H. Peter Anvin" , Peter Zijlstra , Andrea Arcangeli , Johannes Weiner , Larry Woodman , Rik van Riel , Dave Airlie , Brendan Conoboy , Joe Donohue , Duncan Poole , Sherry Cheung , Subhash Gutti , John Hubbard , Mark Hairgrove , Lucien Dunning , Cameron Buschardt , Arvind Gopalakrishnan , Shachar Raindel , Liran Liss , Roland Dreier , Ben Sander , Greg Stoner , John Bridgman , Michael Mantor , Paul Blinzer , Laurent Morichetti , Alexander Deucher , Oded Gabbay , linux-fsdevel@vger.kernel.org, Linda Wang , Kevin E Martin , Jerome Glisse , Jeff Law , Haggai Eran , Or Gerlitz , Sagi Grimberg On Mon, 10 Nov 2014, j.glisse@gmail.com wrote: > In a nutshell HMM is a subsystem that provide an easy to use api to mirror a > process address on a device with minimal hardware requirement (mainly device > page fault and read only page mapping). This does not rely on ATS and PASID > PCIE extensions. It intends to supersede those extensions by allowing to move > system memory to device memory in a transparent fashion for core kernel mm > code (ie cpu page fault on page residing in device memory will trigger > migration back to system memory). Could we define a new NUMA node that maps memory from the GPU and then simply use the existing NUMA features to move a process over there. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org