From: Mark Brown <broonie@kernel.org>
To: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: linux-spi@vger.kernel.org, "Jan Kundrát" <jan.kundrat@cesnet.cz>
Subject: Re: High CPU load when using MAX14830 SPI UART controller
Date: Tue, 19 May 2020 16:24:49 +0100 [thread overview]
Message-ID: <20200519152449.GM4611@sirena.org.uk> (raw)
In-Reply-To: <20200519163353.20c03286@windsurf.home>
[-- Attachment #1: Type: text/plain, Size: 1983 bytes --]
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-05-19 15:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-19 14:33 High CPU load when using MAX14830 SPI UART controller Thomas Petazzoni
2020-05-19 15:24 ` Mark Brown [this message]
2020-05-20 10:18 ` Thomas Petazzoni
2020-05-20 11:26 ` Mark Brown
2020-07-21 13:39 ` Thomas Petazzoni
2020-07-21 22:30 ` Mark Brown
2020-05-20 10:44 ` Jan Kundrát
2020-07-21 13:51 ` Thomas Petazzoni
2020-07-21 14:20 ` Jan Kundrát
2020-07-21 21:49 ` Andy Shevchenko
2020-07-28 8:22 ` Thomas Petazzoni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200519152449.GM4611@sirena.org.uk \
--to=broonie@kernel.org \
--cc=jan.kundrat@cesnet.cz \
--cc=linux-spi@vger.kernel.org \
--cc=thomas.petazzoni@bootlin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).