WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] Question regarding SLAB corruption

To: Lukas Hejtmanek <xhejtman@xxxxxxxxxxx>
Subject: Re: [Xen-devel] Question regarding SLAB corruption
From: Roland Dreier <rdreier@xxxxxxxxx>
Date: Mon, 09 Jul 2007 14:53:53 -0700
Authentication-results: sj-dkim-1; header.From=rdreier@xxxxxxxxx; dkim=pass ( sig from cisco.com/sjdkim1004 verified; );
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir@xxxxxxxxxxxxx>
Delivery-date: Tue, 10 Jul 2007 10:13:47 -0700
Dkim-signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1037; t=1184018043; x=1184882043; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdreier@xxxxxxxxx; z=From:=20Roland=20Dreier=20<rdreier@xxxxxxxxx> |Subject:=20Re=3A=20[Xen-devel]=20Question=20regarding=20SLAB=20corruptio n |Sender:=20; bh=NrSCbwvsjM5BDzXmZqSP6125dOmkVja/IwDyxAiUAgE=; b=dUpXkcQWjxwPBo0woFUNF34VunIolFTmSP/AVppI5W7JNZOPAQACSoDEw7Dvzh7UbT+AQkFl 7+EezoDOF5YnLGsxUn+QWiiAKELcPkwlwcSIN8eTWlerXZHRoUGeT2EQxMpsiq4jWml/UurWb0 C3sqbsfC98RjNj/ZEihy3ST/I=;
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070709214234.GW3885@xxxxxxxxxxx> (Lukas Hejtmanek's message of "Mon, 9 Jul 2007 23:42:34 +0200")
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <C2B83D37.A8DF%keir@xxxxxxxxxxxxx> <adafy3xz8f7.fsf@xxxxxxxxx> <20070709205607.GT3885@xxxxxxxxxxx> <adaps31xp4u.fsf@xxxxxxxxx> <20070709211437.GU3885@xxxxxxxxxxx> <adahcodxola.fsf@xxxxxxxxx> <20070709214234.GW3885@xxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.20 (linux)
 > 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.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>