| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] USB virt status --- Help please!!!
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
|
|
|
| |
|
Home