All of lore.kernel.org
 help / color / mirror / Atom feed
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!]

             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.