Messages in this thread | | | Date | Tue, 28 Nov 2023 16:54:23 +0000 | Subject | Re: Bug in add_dma_entry()'s debugging code | From | Robin Murphy <> |
| |
On 28/11/2023 4:34 pm, Andy Shevchenko wrote: > On Tue, Nov 28, 2023 at 6:31 PM Robin Murphy <robin.murphy@arm.com> wrote: >> On 28/11/2023 3:18 pm, Alan Stern wrote: >>> On Tue, Nov 28, 2023 at 02:37:02PM +0100, Christoph Hellwig wrote: > > ... > >>>> The logical confcusion from that would be that IFF dma-debug is enabled on >>>> any platform we need to set ARCH_DMA_MINALIGN to the cache line size. >>> >>> (IF, not IFF.) And tell distributions that CONFIG_DMA_API_DEBUG is not >>> meant for production systems but rather for kernel testing, right? >> >> Yikes, I'd hope that distros are heeding the warning that the Kconfig >> calls out already. It's perhaps somewhat understated, as I'd describe >> the performance impact to large modern systems with high-bandwidth I/O >> as somewhere between "severe" and "crippling". > > Independently on the distros configurations the (false positive) > message(s) will make difficult to debug the actual things, shouldn't > we have our code robust in any case?
Sure, I have no objection to making dma-debug more robust and useful for its intended purpose, I was just commenting on the fact that any potential change in behaviour from this should be of less concern to distros than the significant change in behaviour that enabling it *already* poses (i.e. globally serialising DMA operations and doing inherently slow stuff in what are normally expected to be fast paths).
Thanks, Robin.
| |