The patch allows for quantifying varios I/O delays. Let's consider a swap request. Swapping a document is done in several steps. First, the corresponding file should be opened for reading or created for writing. This requires an open(2) system call which may incur significant OS overhead: An open(2) call may result in extra I/Os if OS has to write/read i-nodes to/from disk. Then the content in swapped to/from disk using blocks of fixed size. Disk cache and various delays in-between these I/Os affect the total response time.

To estimate the OS overhead on swapping a file we plot the median disk response time of a request versus file size. Response times for files smaller than 16 KB were grouped using 1 KB granularity. Larger files used 1 KB granularity to get enough entries per group. The graph is based on the 24 hour data.

Squid attempts to swap files using blocks of fixed length (e.g. 8 KB). For each I/O direction, we plot the total request response time and the time it takes to swap the first block. The "total" and "1st delay" curves for files smaller than 8 KB are the same.

Since various per I/O delays dominate disk transfer time, the size of an I/O is not very important (the number of I/Os is). This explains step-like shape of the "total" curves: If I/O block size is 8 KB, the times to read 5 KB and 8 KB are the same!

The first disk delay always includes OS overhead on opening a file. Consecutive I/Os for the same file (if any) do not have this overhead. Thus, for file sizes equal to two I/O blocks (16 KB), the difference between the first delay and second I/O approximates OS overhead on opening a file. The patch does not measure the duration of the second I/O. However, we can compute it, assuming that overhead does not depend on the file size for small files:

    1st_Delay   = Overhead + I/O
    Total( 8KB) = 1s_Delay
    Total(16KB) = 1s_Delay + I/O
 =>
    I/O      = Total(16KB) - Total( 8KB)
    Overhead = Total( 8KB) - I/O