<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><BR><BR>unsubscribe<BR><BR>
<HR id=stopSpelling>
> Date: Fri, 8 Feb 2008 16:16:34 -0800<BR>> From: clameter@sgi.com<BR>> To: rdreier@cisco.com<BR>> CC: akpm@linux-foundation.org; andrea@qumranet.com; a.p.zijlstra@chello.nl; linux-mm@kvack.org; izike@qumranet.com; steiner@sgi.com; linux-kernel@vger.kernel.org; avi@qumranet.com; kvm-devel@lists.sourceforge.net; daniel.blueman@quadrics.com; holt@sgi.com; general@lists.openfabrics.org<BR>> Subject: Re: [ofa-general] Re: [patch 0/6] MMU Notifiers V6<BR>> <BR>> On Fri, 8 Feb 2008, Roland Dreier wrote:<BR>> <BR>> > In general, this MMU notifier stuff will only be useful to a subset of<BR>> > InfiniBand/RDMA hardware. Some adapters are smart enough to handle<BR>> > changing the IO virtual -> bus/physical mapping on the fly, but some<BR>> > aren't. For the dumb adapters, I think the current ib_umem_get() is<BR>> > pretty close to as good as we can get: we have to keep the physical<BR>> > pages pinned for as long as the adapter is allowed to DMA into the<BR>> > memory region.<BR>> <BR>> I thought the adaptor can always remove the mapping by renegotiating <BR>> with the remote side? Even if its dumb then a callback could notify the <BR>> driver that it may be required to tear down the mapping. We then hold the <BR>> pages until we get okay by the driver that the mapping has been removed.<BR>> <BR>> We could also let the unmapping fail if the driver indicates that the <BR>> mapping must stay.<BR>> --<BR>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in<BR>> the body of a message to majordomo@vger.kernel.org<BR>> More majordomo info at http://vger.kernel.org/majordomo-info.html<BR>> Please read the FAQ at http://www.tux.org/lkml/<BR><br /><hr />Shed those extra pounds with MSN and The Biggest Loser! <a href='http://biggestloser.msn.com/' target='_new'>Learn more.</a></body>
</html>