From mboxrd@z Thu Jan 1 00:00:00 1970 From: Roland Dreier Subject: Re: Question regarding SLAB corruption Date: Mon, 09 Jul 2007 14:53:53 -0700 Message-ID: References: <20070709205607.GT3885@ics.muni.cz> <20070709211437.GU3885@ics.muni.cz> <20070709214234.GW3885@ics.muni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: In-Reply-To: <20070709214234.GW3885@ics.muni.cz> (Lukas Hejtmanek's message of "Mon, 9 Jul 2007 23:42:34 +0200") List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Lukas Hejtmanek Cc: xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org > Great! With this "fix", it turns on interface ib0. Many thanks to all! in domU? That is cool. > Anyway, is this fix limiting some features, latencies or throughput? It is getting rid of the FMR feature entirely and also affecting memory registration speed. Although going through an swiotlb memcpy may eliminate the memory registration speed advantage. Anyway things are quite useful without the direct write to the MTT -- I think Lustre may be the only thing that *has* to have FMRs, and the memory registration optimization is not that important; we didn't have it for quite a while and it wasn't *that* big a deal. Anyway I think the real fix is to switch to dma_sync_single_range in mthca along with Keir's fixes to swiotlb. Although I'm a little confused about the earlier parts of the story. Why was it necessary to force the use of swiotlb? Shouldn't things work by default? And is there any more intelligent way to give big chunks of system memory to a PCI device for exclusive use? - R.