From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030625AbbDWTZF (ORCPT ); Thu, 23 Apr 2015 15:25:05 -0400 Received: from e38.co.us.ibm.com ([32.97.110.159]:46083 "EHLO e38.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030425AbbDWTZB (ORCPT ); Thu, 23 Apr 2015 15:25:01 -0400 Date: Thu, 23 Apr 2015 12:24:56 -0700 From: "Paul E. McKenney" To: Christoph Lameter Cc: Jerome Glisse , linux-kernel@vger.kernel.org, linux-mm@kvack.org, jglisse@redhat.com, mgorman@suse.de, aarcange@redhat.com, riel@redhat.com, airlied@redhat.com, benh@kernel.crashing.org, 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 Message-ID: <20150423192456.GQ5561@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150421214445.GA29093@linux.vnet.ibm.com> <20150422000538.GB6046@gmail.com> <20150422131832.GU5561@linux.vnet.ibm.com> <20150422170737.GB4062@gmail.com> <20150422185230.GD5561@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15042319-0029-0000-0000-00000950E8D8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 23, 2015 at 09:12:38AM -0500, Christoph Lameter wrote: > On Wed, 22 Apr 2015, Paul E. McKenney wrote: > > > Agreed, the use case that Jerome is thinking of differs from yours. > > You would not (and should not) tolerate things like page faults because > > it would destroy your worst-case response times. I believe that Jerome > > is more interested in throughput with minimal change to existing code. > > As far as I know Jerome is talkeing about HPC loads and high performance > GPU processing. This is the same use case. The difference is sensitivity to latency. You have latency-sensitive HPC workloads, and Jerome is talking about HPC workloads that need high throughput, but are insensitive to latency. > > Let's suppose that you and Jerome were using GPGPU hardware that had > > 32,768 hardware threads. You would want very close to 100% of the full > > throughput out of the hardware with pretty much zero unnecessary latency. > > In contrast, Jerome might be OK with (say) 20,000 threads worth of > > throughput with the occasional latency hiccup. > > > > And yes, support for both use cases is needed. > > What you are proposing for High Performacne Computing is reducing the > performance these guys trying to get. You cannot sell someone a Volkswagen > if he needs the Ferrari. You do need the low-latency Ferrari. But others are best served by a high-throughput freight train. Thanx, Paul