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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.