Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966298AbbDWOU6 (ORCPT ); Thu, 23 Apr 2015 10:20:58 -0400 Received: from resqmta-ch2-09v.sys.comcast.net ([69.252.207.41]:49392 "EHLO resqmta-ch2-09v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964922AbbDWOU4 (ORCPT ); Thu, 23 Apr 2015 10:20:56 -0400 Date: Thu, 23 Apr 2015 09:20:55 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Benjamin Herrenschmidt cc: paulmck@linux.vnet.ibm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jglisse@redhat.com, mgorman@suse.de, aarcange@redhat.com, riel@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 In-Reply-To: <1429756070.4915.17.camel@kernel.crashing.org> Message-ID: 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> <1429756070.4915.17.camel@kernel.crashing.org> Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1480 Lines: 33 On Thu, 23 Apr 2015, Benjamin Herrenschmidt wrote: > > There are hooks in glibc where you can replace the memory > > management of the apps if you want that. > > We don't control the app. Let's say we are doing a plugin for libfoo > which accelerates "foo" using GPUs. There are numerous examples of malloc implementation that can be used for apps without modifying the app. > > Now some other app we have no control on uses libfoo. So pointers > already allocated/mapped, possibly a long time ago, will hit libfoo (or > the plugin) and we need GPUs to churn on the data. IF the GPU would need to suspend one of its computation thread to wait on a mapping to be established on demand or so then it looks like the performance of the parallel threads on a GPU will be significantly compromised. You would want to do the transfer explicitly in some fashion that meshes with the concurrent calculation in the GPU. You do not want stalls while GPU number crunching is ongoing. > The point I'm making is you are arguing against a usage model which has > been repeatedly asked for by large amounts of customer (after all that's > also why HMM exists). I am still not clear what is the use case for this would be. Who is asking for this? -- 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/