From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Stephen C. Tweedie" Subject: Re: USB virt status --- Help please!!! Date: Mon, 14 Nov 2005 13:50:39 -0500 Message-ID: <1131994239.3989.41.camel@orbit.scot.redhat.com> References: <1131906498.7898.20.camel@localhost> <1131963126.28635.3.camel@localhost.localdomain> <4b44eaf35c9bb921b7940c157936c38a@cl.cam.ac.uk> <1131989401.3989.19.camel@orbit.scot.redhat.com> <681ca7ec21d7aac712bae9e9cde2c493@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <681ca7ec21d7aac712bae9e9cde2c493@cl.cam.ac.uk> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Ian Pratt , harry , xen-devel@lists.xensource.com, sanjay.kushwaha@gmail.com, mark.williamson@cl.cam.ac.uk List-Id: xen-devel@lists.xenproject.org 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