From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) by kanga.kvack.org (Postfix) with ESMTP id 68F7F6B0036 for ; Tue, 6 May 2014 12:54:16 -0400 (EDT) Received: by mail-qc0-f179.google.com with SMTP id x3so6373702qcv.38 for ; Tue, 06 May 2014 09:54:16 -0700 (PDT) Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [2607:f8b0:400d:c04::230]) by mx.google.com with ESMTPS id n7si5397315qas.171.2014.05.06.09.54.14 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 May 2014 09:54:14 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id i50so8163859qgf.7 for ; Tue, 06 May 2014 09:54:14 -0700 (PDT) Date: Tue, 6 May 2014 12:54:08 -0400 From: Jerome Glisse Subject: Re: [RFC] Heterogeneous memory management (mirror process address space on a device mmu). Message-ID: <20140506165405.GE6731@gmail.com> References: <1399038730-25641-1-git-send-email-j.glisse@gmail.com> <20140506102925.GD11096@twins.programming.kicks-ass.net> <20140506150014.GA6731@gmail.com> <20140506153315.GB6731@gmail.com> <53690E29.7060602@redhat.com> <53691214.80906@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <53691214.80906@redhat.com> Sender: owner-linux-mm@kvack.org List-ID: To: Rik van Riel Cc: Linus Torvalds , Peter Zijlstra , linux-mm , Linux Kernel Mailing List , linux-fsdevel , Mel Gorman , "H. Peter Anvin" , Andrew Morton , Linda Wang , Kevin E Martin , Jerome Glisse , Andrea Arcangeli , Johannes Weiner , Larry Woodman , Dave Airlie , Jeff Law , Brendan Conoboy , Joe Donohue , Duncan Poole , Sherry Cheung , Subhash Gutti , John Hubbard , Mark Hairgrove , Lucien Dunning , Cameron Buschardt , Arvind Gopalakrishnan , Haggai Eran , Or Gerlitz , Sagi Grimberg , Shachar Raindel , Liran Liss , Roland Dreier , "Sander, Ben" , "Stoner, Greg" , "Bridgman, John" , "Mantor, Michael" , "Blinzer, Paul" , "Morichetti, Laurent" , "Deucher, Alexander" , "Gabbay, Oded" , Davidlohr Bueso On Tue, May 06, 2014 at 12:47:16PM -0400, Rik van Riel wrote: > On 05/06/2014 12:34 PM, Linus Torvalds wrote: > > On Tue, May 6, 2014 at 9:30 AM, Rik van Riel wrote: > >> > >> The GPU runs a lot faster when using video memory, instead > >> of system memory, on the other side of the PCIe bus. > > > > The nineties called, and they want their old broken model back. > > > > Get with the times. No high-performance future GPU will ever run > > behind the PCIe bus. We still have a few straggling historical > > artifacts, but everybody knows where the future is headed. > > > > They are already cache-coherent because flushing caches etc was too > > damn expensive. They're getting more so. > > I suppose that VRAM could simply be turned into a very high > capacity CPU cache for the GPU, for the case where people > want/need an add-on card. > > With a few hundred MB of "CPU cache" on the video card, we > could offload processing to the GPU very easily, without > having to worry about multiple address or page table formats > on the CPU side. > > A new generation of GPU hardware seems to come out every > six months or so, so I guess we could live with TLB > invalidations to the first generations of hardware being > comically slow :) > I do not want to speak for any GPU manufacturer but i think it is safe to say that there will be dedicated memory for GPU for a long time. It is not going anywhere soon and it is a lot more than few hundred MB, think several GB. If you think about 4k, 8k screen you really gonna want 8GB at least on desktop computer and for compute you will likely see 16GB or 32GB as common size. Again i stress that there is nothing on the horizon that let me believe that regular memory associated to CPU will ever come close to the bandwith that exist with memory associated to GPU. It is already more than 10 times faster on GPU and as far as i know the gap will grow even more in the next generation. So dedicated memory to gpu should not be discarded as something that is vanishing quite the contrary it should be acknowledge as something that is here to stay a lot longer afaict. Cheers, Jerome -- 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