Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966632AbbDWR3S (ORCPT ); Thu, 23 Apr 2015 13:29:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59794 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966493AbbDWR3P (ORCPT ); Thu, 23 Apr 2015 13:29:15 -0400 Message-ID: <55392BD9.6070305@redhat.com> Date: Thu, 23 Apr 2015 13:28:57 -0400 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Christoph Lameter , Jerome Glisse CC: Benjamin Herrenschmidt , paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jglisse@redhat.com, mgorman@suse.de, aarcange@redhat.com, airlied@redhat.com, aneesh.kumar@linux.vnet.ibm.com, Cameron Buschardt , Mark Hairgrove , Geoffrey Gerfin , John McKenna , akpm@linux-foundation.org Subject: Re: Interacting with coherent memory on external devices References: <20150421214445.GA29093@linux.vnet.ibm.com> <1429663372.27410.75.camel@kernel.crashing.org> <20150422005757.GP5561@linux.vnet.ibm.com> <1429664686.27410.84.camel@kernel.crashing.org> <20150422163135.GA4062@gmail.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1089 Lines: 26 On 04/22/2015 01:14 PM, Christoph Lameter wrote: > On Wed, 22 Apr 2015, Jerome Glisse wrote: > >> Glibc hooks will not work, this is about having same address space on >> CPU and GPU/accelerator while allowing backing memory to be regular >> system memory or device memory all this in a transparent manner to >> userspace program and library. > > If you control the address space used by malloc and provide your own > implementation then I do not see why this would not work. Your program does not know how many other programs it is sharing the co-processor / GPU device with, which means it does not know how much of the co-processor or GPU memory will be available for it at any point in time. Well, in your specific case your program might know, but in the typical case it will not. This means the OS will have to manage the resource. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/