On Tue, May 19, 2020 at 04:33:53PM +0200, Thomas Petazzoni wrote: > perf record/report gives: > 19.42% spi1 [kernel.kallsyms] [k] finish_task_switch > 17.42% kworker/u2:1-ev [kernel.kallsyms] [k] finish_task_switch > 9.22% irq/50-spi1.3 [kernel.kallsyms] [k] atmel_spi_transfer_one_message > 7.76% irq/50-spi1.3 [kernel.kallsyms] [k] finish_task_switch > 4.15% irq/50-spi1.3 [kernel.kallsyms] [k] schedule_timeout > 4.15% kworker/0:2-eve [kernel.kallsyms] [k] finish_task_switch > 2.25% swapper [kernel.kallsyms] [k] arch_cpu_idle > 1.94% irq/50-spi1.3 [kernel.kallsyms] [k] __spi_pump_messages > 1.84% irq/50-spi1.3 [kernel.kallsyms] [k] __spi_validate > 1.78% irq/50-spi1.3 [kernel.kallsyms] [k] spi_finalize_current_message > Does the very high CPU time spent in finish_task_switch() simply means > that we're scheduling too much ? > Any hints on how to improve this situation ? Not thinking about this too deeply... The copybreak for DMA in spi-ateml is 16 bytes so at 20 byte reads (assuming that's what actually ends up as a SPI transfer) it might be worth looking at tuning that and seeing if PIO helps, though I'm not seeing any DMA stuff showing up there. The other thing that jumps out looking at the code is that in the interrupts to complete transfers the driver will just complete() and wake the main transfer thread up, for the reads where we always have two transfers per message this will cause an extra context switch. If the driver were able to initiate the next transfer directly from interrupt context then it should schedule less (and generally reduce latency too). I can't really see much obvious in the serial driver - it might want to consider error checking, or if it doesn't care if transfers complete it might want to switch to async SPI calls, but nothing that looks like there's anything obvious for SPI related that you could do here.
Attachment:
signature.asc
Description: PGP signature
