Re: [Xen-devel] USB virt status --- Help please!!!

["Stephen C. Tweedie" <sct@xxxxxxxxxx>]

Hi,

On Mon, 2005-11-14 at 18:42 +0000, Keir Fraser wrote:

> > That got fixed that by adding an arch-specific __alloc_skb which 
> > avoided
> > crossing page boundaries by disabling CONFIG_DEBUG_SLAB for the skb
> > caches.  But that fix is also something that I doubt maintainers will
> > allow to go upstream.  I wonder if we'll find enough such special cases
> > that we really want to have a swiotlb available, just in case, at all
> > times?
> 
> swiotlb performance is pretty poor since it involves memcpy. The 
> alloc_skb fix was pretty clean, if we're allowed an arch hook for 
> alloc_skb. We didn;t need to hack the slab allocator itself.

There are two different questions --- whether we should rely on swiotlb
in the general case, and whether we should have it available
just-in-case for edge cases.

I'm not suggesting that we fix the networking problem via swiotlb.  But
that problem does make me wonder what other edge-cases remain lurking
that may bite users later; and if they exist, panicing the kernel when
we get an IO we can't translate directly is a lot worse than falling
back to a slow swiotlb path.

The fact is, on 2.6 the slab allocator can hand out objects (even
sub-pagesized ones) that cross page boundaries.  If some driver happens
to allocate its own objects from a slab cache and run pci_map_single()
on them, it works fine on 2.6 mainline but breaks on Xen w/o swiotlb.

The alloc_skb is just avoiding one special case of this.  It's an
important special case, sure, but to be robust, might we not want to
have a minimal swiotlb cache available at all times as fallback?

--Stephen



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