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] [PATCH 03 of 38] swiotlb: allow architectures tooverride

To: Chris Lalancette <clalance@xxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 03 of 38] swiotlb: allow architectures tooverride swiotlb pool allocation
From: Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
Date: Mon, 17 Nov 2008 08:44:20 +0000
Cc: the arch/x86 maintainers <x86@xxxxxxxxxx>, Ingo Molnar <mingo@xxxxxxx>, Xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>, Ian Campbell <ian.campbell@xxxxxxxxxx>, linux-kernel@xxxxxxxxxxxxxxx
Delivery-date: Mon, 17 Nov 2008 00:44:47 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49212587.8020702@xxxxxxxxxx>
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/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AclIkK6v7PwvhLSDEd2TBAAWy6hiGQ==
Thread-topic: [Xen-devel] [PATCH 03 of 38] swiotlb: allow architectures tooverride swiotlb pool allocation
User-agent: Microsoft-Entourage/11.4.0.080122
On 17/11/08 08:04, "Chris Lalancette" <clalance@xxxxxxxxxx> wrote:

>> Could you be more specific?  The swiotlb allocation should be machine
>> contiguous and so there's no stradding required, but I think I'm missing
>> your point.
> 
> In general, I think you are right; swiotlb should be machine contiguous, so it
> works in the normal case.  The range_straddles_page_boundary function takes
> care
> of a corner case, where you can run into swiotlb exhaustion when you really
> shouldn't.  As I understand it, it comes about because it is possible to get a
> swiotlb request with two pages that just happen to be machine contiguous, but
> were *not* allocated through xen_create_contiguous_region (and hence weren't
> marked in the contiguous_bitmap as such).  In this case, you split the request
> into two separate requests, and this can more easily lead to exhaustion.
> range_straddles_page_boundary works around this by checking whether any two
> pages coming through the swiotlb layer are machine contiguous, and if they
> are,
> not splitting the request.

A more specific problem solved by range_straddle_page_boundary() in our
2.6.18 kernel was that the block layer would do bio merging because it
checked that pages really were contiguous, and then swiotlb (without
r_s_p_b) would decide that the pages weren't contiguous (because the
contiguity was random luck rather than explicitly requested) and hence do
bounce buffering. Result was that sufficiently aggressive I/O would exhaust
swiotlb resources and crash the kernel.

In the 2.6.18 port we actually got rid of contiguous_bitmap[] entirely.

 -- Keir



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

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