From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759626Ab2CTKxS (ORCPT ); Tue, 20 Mar 2012 06:53:18 -0400 Received: from mx1.redhat.com ([209.132.183.28]:27309 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757747Ab2CTKxR (ORCPT ); Tue, 20 Mar 2012 06:53:17 -0400 Message-ID: <4F686163.40509@redhat.com> Date: Tue, 20 Mar 2012 12:52:19 +0200 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1 MIME-Version: 1.0 To: Peter Zijlstra CC: Linus Torvalds , Andrew Morton , Thomas Gleixner , Ingo Molnar , Paul Turner , Suresh Siddha , Mike Galbraith , "Paul E. McKenney" , Lai Jiangshan , Dan Smith , Bharata B Rao , Lee Schermerhorn , Andrea Arcangeli , Rik van Riel , Johannes Weiner , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [RFC][PATCH 00/26] sched/numa References: <20120316144028.036474157@chello.nl> <4F670325.7080700@redhat.com> <1332155527.18960.292.camel@twins> <4F671B90.3010209@redhat.com> <1332158992.18960.316.camel@twins> <4F672384.1030601@redhat.com> <1332187387.18960.389.camel@twins> <4F685960.4080904@redhat.com> <1332240525.18960.403.camel@twins> In-Reply-To: <1332240525.18960.403.camel@twins> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/20/2012 12:48 PM, Peter Zijlstra wrote: > On Tue, 2012-03-20 at 12:18 +0200, Avi Kivity wrote: > > On 03/19/2012 10:03 PM, Peter Zijlstra wrote: > > > On Mon, 2012-03-19 at 14:16 +0200, Avi Kivity wrote: > > > > > Afaik we do not use dma engines for memory migration. > > > > > > > > We don't, but I think we should. > > > > > > ISTR we (the community) had this discussion once. I also seem to > > > remember the general consensus being that DMA engines would mostly > > > likely not be worth the effort, although I can't really recall the > > > specifics. > > > > > > Esp. for 4k pages the setup of the offload will likely be more expensive > > > than actually doing the memcpy. > > > > If you're copying a page, yes. If you're copying a large vma, the > > per-page setup cost is likely to be very low. > > > > Especially if you're copying across nodes. > > But wouldn't you then have to wait for the entire copy to complete > before accessing any of the memory? That sounds like a way worse latency > hit than the per-page lazy-migrate. You use the dma engine for eager copying, not on demand. -- error compiling committee.c: too many arguments to function