On Thu, Apr 23, 2015 at 09:20:55AM -0500, Christoph Lameter wrote: > 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. Except that the app might be mapping a file or operating on a big array in bss instead of (or as well as) using malloc()ed memory. > > 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. Yep. But for throughput-oriented applications, as long as stalls don't happen very often, this can be OK. > > 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? Ben and I are. I have added a use case, which I will send out shortly with the next version. Thanx, Paul -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>