From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by kanga.kvack.org (Postfix) with ESMTP id 2B9446B0032 for ; Thu, 23 Apr 2015 13:29:09 -0400 (EDT) Received: by wiun10 with SMTP id n10so100466081wiu.1 for ; Thu, 23 Apr 2015 10:29:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id a17si14875523wjz.67.2015.04.23.10.29.06 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Apr 2015 10:29:07 -0700 (PDT) Message-ID: <55392BD9.6070305@redhat.com> Date: Thu, 23 Apr 2015 13:28:57 -0400 From: Rik van Riel MIME-Version: 1.0 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: owner-linux-mm@kvack.org List-ID: 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 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, 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 From mboxrd@z Thu Jan 1 00:00:00 1970 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 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.