From: Mason <mpeg.blue@free.fr>
To: linux-kernel@vger.kernel.org
Cc: linux-embedded@vger.kernel.org, linux-ide@vger.kernel.org
Subject: Using ftrace to identify source of excessive latency of USB write
Date: Sun, 27 Apr 2014 21:17:35 +0200 [thread overview]
Message-ID: <535D57CF.50402@free.fr> (raw)
Hello everyone,
I'm using Linux on a embedded system similar in spec to a desktop PC
from 15 years ago (256 MB RAM, 800-MHz CPU, USB). The system's primary
use is recording high-definition digital television programs.
Typically, the storage sub-system consists of a recent hard-disk drive
connected over USB (Hi-Speed, effective throughput ~20-30 MB/s), using
a single ext4 partition (journal disabled), mounted noexec+noatime
(trying to minimize metadata interference).
Typical bit-rate for this HD content ~1-3 MB/s
Data is accumulated in two 800-kB buffers; when one buffer is full,
it is written to file (using write(2)), which was opened O_SYNC.
(Note to self: try O_DSYNC instead of O_SYNC)
If I plot the latency of the write(2) operation, 99% of them complete
in under 80 ms. However, in rare cases, there is a huge latency spike
(up to 800 ms). If several of these rare outliers occur in a row,
the recording is messed up.
I am trying to figure out the source of these latency spikes.
It could be the OS, the USB controller, the HDD controller... I was
hoping I could use ftrace to determine whether the problem came from
the OS itself. Is that the best tool for the job?
Any recommendations on how to proceed?
Regards.
[I would be grateful if you could CC me in your replies. Thanks!]
next reply other threads:[~2014-04-27 19:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-27 19:17 Mason [this message]
2014-05-06 9:23 ` Using ftrace to identify source of excessive latency of USB write Mason
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=535D57CF.50402@free.fr \
--to=mpeg.blue@free.fr \
--cc=linux-embedded@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).