Thread (129 messages) 129 messages, 18 authors, 2012-07-14

Re: [RFC][PATCH 00/26] sched/numa

From: Avi Kivity <hidden>
Date: 2012-03-20 10:53:18
Also in: lkml

On 03/20/2012 12:48 PM, Peter Zijlstra wrote:
On Tue, 2012-03-20 at 12:18 +0200, Avi Kivity wrote:
quoted
On 03/19/2012 10:03 PM, Peter Zijlstra wrote:
quoted
On Mon, 2012-03-19 at 14:16 +0200, Avi Kivity wrote:
quoted
quoted
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

--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help