[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [PATCH v2 1/1] swiotlb: Reduce swiotlb pool lookups
On Sun, Jul 07, 2024 at 02:11:48AM +0000, Michael Kelley wrote: > This works pretty well. It certainly avoids the messiness of declaring > a "pool" local variable and needing a separate assignment before the > "if" statement, in each of the 9 call sites. The small downside is that > it looks like a swiotlb function is called every time, even though > there's usually an inline bailout. But that pattern occurs throughout > the kernel, so not a big deal. > > I initially coded this change as a separate patch that goes first. But > the second patch ends up changing about 20 lines that are changed > by the first patch. It's hard to cleanly tease them apart. So I've gone > back to a single unified patch. But let me know if you think it's worth > the extra churn to break them apart. I think it's perfectly fine to keep one big patch. > Yes, this works as long as the declarations for the __swiotlb_foo > functions are *not* under CONFIG_SWIOTLB. But when compiling with > !CONFIG_SWIOTLB on arm64 with gcc-8.5.0, two tangentially related > compile errors occur. iommu_dma_map_page() references > swiotlb_tlb_map_single(). The declaration for the latter is under > CONFIG_SWIOTLB. A similar problem occurs with dma_direct_map_page() > and swiotlb_map(). Do later versions of gcc not complain when the > reference is in dead code? Or are these just bugs that occurred because > !CONFIG_SWIOTLB is rare? If the latter, I can submit a separate patch to > move the declarations out from under CONFIG_SWIOTLB. A reference to dead code is fine as long as the condition is a compile time one. I think your next mail sugests you've sorted this out, but if not let me know or just shared your current work in progress patch. > > if (IS_ENABLED(CONFIG_SWIOTLB_DYNAMIC)) { > > The "IS_ENABLED" doesn't work because the dma_uses_io_tlb > field in struct dev is under CONFIG_SWIOTLB_DYNAMIC. I guess > it could be moved out, but that's going further afield. So I'm back > to using #ifdef. Yes, we'd need the field definition. > Petr Tesařík had commented [1] on my original RFC suggesting that > __swiotlb_find_pool() be used here instead of open coding it. With > the changes you suggest, __swiotlb_find_pool() is needed only in > the CONFIG_SWIOTLB_DYNAMIC case, and I would be fine with just > open coding the address of defpool here. Petr -- are you OK with > removing __swiotlb_find_pool when !CONFIG_SWIOTLB_DYNAMIC, > since this is the only place it would be used? Yes. That was indeed the intent behind the suggstion.
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |