CODEWITHSUNDEEP
clinuxtimediskmeasure
Apollo
Apollo

Reputation: 31

How to measure execution time of file I/Os in C programs on Linux?

I want to measure execution time of file I/Os in C programs on Linux. I found a lot of questions and answers regarding measuring times.

But, I think any of the answers would not work for my purpose.

Functions related with real-time clocks are not proper in my case because I want to exclude time consumed by other processes. (e.g. gettimeofday, clock_gettime(CLOCK_MONOTONIC_RAW))

Functions related with CPU time are not proper in my case, either, because I want to include wait time for disk I/O. (e.g. getrusage, clock, clock_gettime(CLOCK_PROCESS_CPUTIME_ID))

Any suggestions?

Upvotes: 2

Views: 572

Answers (2)

ArborealAnole
ArborealAnole

Reputation: 330

You can use open, read, and write calls for direct measurement of disk I/O speed, avoiding automatic stream buffering (like fopen).

For read and write you should verify bytes read and written.

To time just use clock_gettime(CLOCK_PROCESS_CPUTIME_ID,*tp) or CLOCK_THREAD_CPUTIME_ID (see this question). I say that because Linux includes kernel/system time on behalf of the process (this is explicit on the man entry for clock_gettime only on OpenBSD). You may want to make sure you are filling the disk cache, and potentially the kernel disk page cache, if you want to measure continuous (non-burst) speed. This way your call to open will return only after completing file write.

Only using the above process will give you the results you would get in normal usage using kernel disk page caching. You can further bypass kernel page caching as follows. But keep in mind that these are "raw" results and will not necessarily correspond to results when you are using kernel page caching, as Basile Starynkevitch described.

Call open with O_SYNC|O_DIRECT operating mode flags (see this question). O_DIRECT bypasses kernel page caching. This way your data will be confirmed to be completely transferred to and from disk rather than computer RAM cache.

   O_DIRECT (since Linux 2.4.10)
          Try to minimize cache effects of the I/O to and from this
          file.  In general this will degrade performance, but it is
          useful in special situations, such as when applications do
          their own caching.  File I/O is done directly to/from user-
          space buffers.  The O_DIRECT flag on its own makes an effort
          to transfer data synchronously, but does not give the
          guarantees of the O_SYNC flag that data and necessary metadata
          are transferred.  To guarantee synchronous I/O, O_SYNC must be
          used in addition to O_DIRECT.  See NOTES below for further
          discussion.

Unless I am mistaken you will not have to worry about the kernel scheduling another process onto your CPU in testing unless most of your CPUs are busy. Even if it does schedule another process it may return to your process as soon as the synchronous write has completed (please let me know as a comment if you know). Therefore using CLOCK_MONOTONIC_RAW instead may not matter. cpuset might be useful.

Consult Linux man entries and The GNU C Library Reference Manual. Also see fsync and this question about how long page-cached writes take to hit disk.

Upvotes: 1

Basile Starynkevitch
Basile Starynkevitch

Reputation: 1

Read both time(7) and about the page cache, then a textbook about operating systems.

I want to measure execution time of file I/Os in C programs on Linux

Your question does not make real sense. Disk I/O or file systems is a whole computer activity, not just done by a particular process doing some syscalls(2). For example, find(1) some big file (of several dozens of megabytes) on your system and run time wc several times on it. See wc(1) and time(1).

In particular the kernel would handle page faults (with help from the MMU inside your processor), and a given page can be mmap(2)-ed many times by different processes.

Drepper's paper How to write shared libraries and the dynamic linker (see ld.so(8) ...) are relevant.

In practice, in 2020, most ELF executables are dynamically linked (e.g. to libc.so). See ldd(1), ps(1) and pmap(1) and proc(5).

See also kernelnewbies.org, Advanced Linux Programming, https://www.linuxatemyram.com/

Upvotes: 0

Related Questions