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

[Xen-devel] SWIOMMU redundant copies?

To: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] SWIOMMU redundant copies?
From: "Stephen C. Tweedie" <sct@xxxxxxxxxx>
Date: Fri, 14 Mar 2008 15:50:28 +0000
Cc: Stephen Tweedie <sct@xxxxxxxxxx>
Delivery-date: Fri, 14 Mar 2008 08:50:58 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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>
Organization: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hi,

In current linux-2.6.18-xen.h 64-bit, it looks like we're doing
potentially large amounts of unnecessary IO bounce-buffering.

I noticed this when trying to pin down some odd behaviour concerning
changeset 15405 in xen-3.1-testing:

        http://xenbits.xensource.com/xen-3.1-testing.hg?rev/30033a637942

        # User kfraser@xxxxxxxxxxxxxxxxxxxxx
        # Date 1183985110 -3600
        # Node ID 30033a6379428f57269455f0963841743c6d5e46
        # Parent  9cdade953890a612734d97b3abc21513a1a9cf6d
        x86: dma_map_sg() must handle multi-page segments.
        Signed-off-by: Keir Fraser <keir@xxxxxxxxxxxxx>

which adds a test when we do swiotlb_map_sg():

--- a/linux-2.6-xen-sparse/arch/i386/kernel/swiotlb.c   Fri Sep 14 16:33:44 
2007 +0100
+++ b/linux-2.6-xen-sparse/arch/i386/kernel/swiotlb.c   Mon Jul 09 13:45:10 
2007 +0100
@@ -572,7 +572,9 @@ swiotlb_map_sg(struct device *hwdev, str
 
        for (i = 0; i < nelems; i++, sg++) {
                dev_addr = SG_ENT_PHYS_ADDRESS(sg);
-               if (address_needs_mapping(hwdev, dev_addr)) {
+               if (range_straddles_page_boundary(page_to_pseudophys(sg->page)
+                                                 + sg->offset, sg->length)
+                   || address_needs_mapping(hwdev, dev_addr)) {
                        buffer.page   = sg->page;

This is still present in linux-2.6.18-xen.hg's lib/swiotlb-xen.c; but it
seems to conflict with a different test that we use when we merge bios
together for multi-page disk IO, where we have

include/asm-x86_64/mach-xen/asm/io.h:
#define page_to_pseudophys(page) ((dma_addr_t)page_to_pfn(page) << PAGE_SHIFT)
#define page_to_phys(page)       (phys_to_machine(page_to_pseudophys(page)))
#define page_to_bus(page)        (phys_to_machine(page_to_pseudophys(page)))

#define bio_to_pseudophys(bio)   (page_to_pseudophys(bio_page((bio))) + \
                                  (unsigned long) bio_offset((bio)))
#define bvec_to_pseudophys(bv)   (page_to_pseudophys((bv)->bv_page) + \
                                  (unsigned long) (bv)->bv_offset)

#define BIOVEC_PHYS_MERGEABLE(vec1, vec2)       \
        (((bvec_to_phys((vec1)) + (vec1)->bv_len) == bvec_to_phys((vec2))) && \
         ((bvec_to_pseudophys((vec1)) + (vec1)->bv_len) == \
          bvec_to_pseudophys((vec2))))

This test in io.h basically means that bios can, and will, span page
boundaries if the pages in question are both physical- and machine-
contiguous; but the range_straddles_page_boundary test does NOT check
for machine-contiguous pages (it only tests whether pages are in a
xen_create_contiguous_region() region, not whether pages happen to be
contiguous by chance in non-guaranteed-contig regions.)

So we'll create bios which span multiple pages, assuming that that's
more efficient; but then we'll force them to be copied because they span
multiple pages!

Have I missed something, or is this an oversight in the swiotlb.c patch
above?

The reason I discovered this is that including the patch seems to be
causing SWIOTLB overflows on some hardware.  Adding an extra test to
swiotlb_map_sg() to catch sg segments which are truly machine-contig and
don't need mapping, and avoid copying those, cures those symptoms for
me, but I suspect there may be other issues lurking in this area.

Cheers,
 Stephen



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

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